Re: [PATCH] http-backend: treat empty CONTENT_LENGTH as zero

From

Junio C Hamano <gitster@pobox.com>

Date

Sep 11, 2018, 18:27 UTC

Message-ID

<xmqqa7onq490.fsf@gitster-ct.c.googlers.com>

In-Reply-To

<xmqqk1nrq4su.fsf@gitster-ct.c.googlers.com>

Junio C Hamano <gitster@pobox.com> 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.

 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"))