Joe Orton wrote:
On Wed, Jun 22, 2005 at 03:02:50PM -0500, William Rowe wrote:
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.
I don't see any reason to reject anything, 2616 dictates precisely how
to handle requests which are malformed in this way. I do think the
check against "identity" is actually redundant, though; not least
because the 2616 errata remove all references to the word.
I think correct behaviour is to just follow the letter of Section 4.4,
point 3, as below:
If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
(and it's also going to be better to check for T-E before C-L since
99.99% of requests received are not going to have a T-E header so it'll
fall through slightly quicker)
+1 to the posted patch.
-Paul
