Junio C Hamano <[email protected]> writes:
>>> + /*
>>> + * According to RFC 3875, an empty or missing
>>> + * CONTENT_LENGTH means "no body", but RFC 3875
>>> + * precedes HTTP/1.1 and chunked encoding. Apache and
>>> + * its imitators leave CONTENT_LENGTH unset for
>>
>> Which imitators? Maybe this should just say "Apache leaves [...]".
>
> I tend to agree; I do not mind amending the text while queuing.
> ...
> I do not think we would mind terribly if we do not support
> combinations like gzipped-and-then-chunked from day one. An in-code
> NEEDSWORK comment that refers to the production in RFC 2616 Page 143
> may not hurt, though.
I refrained from reflowing the first paragraph of the comment in
this message, but will probably reflow it before committing, if the
updated text is acceptable.
http-backend.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index 8f515a6def..b997eafb00 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -357,10 +357,17 @@ static ssize_t get_content_length(void)
/*
* According to RFC 3875, an empty or missing
* CONTENT_LENGTH means "no body", but RFC 3875
- * precedes HTTP/1.1 and chunked encoding. Apache and
- * its imitators leave CONTENT_LENGTH unset for
+ * precedes HTTP/1.1 and chunked encoding. Apache
+ * leaves CONTENT_LENGTH unset for
* chunked requests, for which we should use EOF to
* detect the end of the request.
+ *
+ * NEEDSWORK: Transfer-Encoding header is defined to
+ * be a list of elements where "chunked", if exists,
+ * must be at the end. The current code only deals
+ * with the case where "chunked" is the only element.
+ * See RFC 2616 (14.41 Transfer-Encoding) when
+ * extending this code.
*/
str = getenv("HTTP_TRANSFER_ENCODING");
if (str && !strcmp(str, "chunked"))
