At 01:57 AM 6/20/2005, jean-frederic clere wrote: >I still need some more time to check POST with 2 different content-lengths and >GET with content-length.
Well, GET with c-l is permitted. 2 C-L headers would be rejected due to the '##, ##' format, where the ', ' is non-numeric. After your patch, in 2.1 we now accept (discard) the C-L headers (even multiples) if we also have T-E: chunked. Prior to your patch we ment to reject the request with C-L and T-E if Paul's patch was entirely correct. Prior to either patch we totally mishandled such requests. So the only question which remains is; which behavior do we prefer? As the RFC states this is not acceptable, my gut says reject ANY request with both C-L and T-E of non-identity. Quoting 4.4 of RFC 2616; For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length. All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored. So I can see where we would ignore C-L, I'm mostly concerned that we never proxy or pass on a C-L passed by a client through our proxy to another UA for non-identity encodings. But rejecting outright seems safer :) Bill
