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)
Index: server/protocol.c
===================================================================
--- server/protocol.c (revision 192995)
+++ server/protocol.c (working copy)
@@ -899,16 +899,13 @@
return r;
}
- if (apr_table_get(r->headers_in, "Content-Length")) {
- const char* te = apr_table_get(r->headers_in, "Transfer-Encoding");
- /*
- * If the client sent any Transfer-Encoding besides "identity",
- * the RFC says we MUST ignore the C-L header. We kill it here
- * to prevent more work later on in modules like mod_proxy.
- */
- if (te && strcasecmp("identity", te) != 0) {
- apr_table_unset(r->headers_in, "Content-Length");
- }
+ if (apr_table_get(r->headers_in, "Transfer-Encoding")
+ && apr_table_get(r->headers_in, "Content-Length")) {
+ /* 2616 section 4.4, point 3: "if both Transfer-Encoding
+ * and Content-Length are received, the latter MUST be
+ * ignored"; so unset it here to prevent any confusion
+ * later. */
+ apr_table_unset(r->headers_in, "Content-Length");
}
}
else {
