wsgi proxy and 'hop by hop'

[faassen]

The WSGI proxy implementation passes hop-by-hop related headers (like transfer-encoding, connection, etc) through unchanged. According to PEP 3333 these however do not apply to WSGI:

http://legacy.python.org/dev/peps/pep-3333/

Indeed Waitress gives an exception when you try, and mod_wsgi seems to choke on such requests.

Since the WSGI proxy should be a conformant WSGI implementation, it should remove these hop by hop headers. This won't affect chunking, as if the proxy is proxying a chunked response, WSGI will return the chunks one by one in its iterator result. A WSGI server can then add them back again (I've seen Waitress does).

[faassen]

The newest HTTP 1.1 rfc versions don't seem to define hop by hop anymore. They used to be in see RFC 2616, section 13.5.1. RFC 7230 section 6.1 does say that a proxy must remove Connection as well as anything listed in the connection header (unless that's close, I guess).

[faassen]

I've investigated this some more, and here are my conclusions:

http://blog.startifact.com/posts/new-http-rfcs-versus-wsgi.html

Until the WSGI pep is updated I think we should just hardcode the list anyway. We know for sure that not removing these headers won't be compatible with a WSGI server. In fact, Waitress just complains when you try to send out Transfer-Encoding to it from a WSGI app.

[faassen]

Now I wonder whether my analysis was correct. Waitress should be able to handle a hop-by-hop header as it's a HTTP server. I think it complains when the underlying WSGI code tries to generate a hop-by-hop header, which is odd because I didn't think we were...