wsgi: server MUST NOT send Content-Length/Transfer-Encoding header in response with a status code of 1xx, 204 or (2xx to CONNECT request) #747
Conversation
… response with a status code of 1xx, 204 or (2xx to CONNECT request) https://httpwg.org/specs/rfc7230.html#rfc.section.3.3.1 #746
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Makes sense, though I think there are two more cases from section 3.3.3 where we may want to skip our standard attempt at imposing a content-length or transfer-encoding on the response:
- responses to
HEADrequests - responses with status
304 Not Modified
While the RFC allows servers to include these headers in such responses, I don't think we're in a position to know what appropriate values are -- only application code can say for sure.
| @@ -479,6 +479,9 @@ def handle_one_response(self): | |||
| use_chunked = [False] | |||
| length = [0] | |||
| status_code = [200] | |||
| # Status code of 1xx or 204 or 2xx to CONNECT request MUST NOT send body and related headers | |||
| # https://httpwg.org/specs/rfc7230.html#rfc.section.3.3.1 | |||
| bodyless = [False] | |||
There was a problem hiding this comment.
It bugs me a little that we're not actually enforcing the absence of a body -- if application code responds 204 No Content but then also returns an app iter that has some bytes, we're going to yield them out and mess up message framing. Bit of a slippery slope to go down, though, I suppose.
There was a problem hiding this comment.
Yes, agreed, thank you. But also we have a funny hack to allow random header case for compatibility with some popular server.
IMHO, we should claim WSGI and HTTP are separated at eventlet.wsgi, it takes care of transfer headers, may drop body and proper application expects that anyway. But also allow things like 204 with body via feature flag.
But it seems a fair amount of change. Suggest to extract this as separate task and implement later.
There was a problem hiding this comment.
Agreed; it can certainly be a follow-up -- or we just tell application developers to be more careful. Definitely not a blocker to getting this fix merged.
https://httpwg.org/specs/rfc7230.html#rfc.section.3.3.1
Fixes #746
Fixes #862