Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

From: Max Kirillov <max@max630.net>
Date: Sep 8, 2018, 05:41 UTC
Message-ID: <20180908054105.GC20545@jessie.local>
In-Reply-To: <xmqqsh2ly6vw.fsf@gitster-ct.c.googlers.com>

On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> Max Kirillov <max@max630.net> writes:
> 
>> Actually, another reason for the latest issue was that CONTENT_LENGTH
>> is parsed for GET requests at all. It should be parsed only for POST
>> requests, or, rather, only for upoad-pack and receive-pack requests.
> 
> Not really.  The layered design of the HTTP protocol means that any
> request type can have non-empty body, but request types for which
> no semantics of the body is defined must ignore what is in the body,
> which in turn means we need to parse and pay attention to the
> content length etc. to find the end of the body, if only to ignore
> it.

I don't think it is git's job to police web server implementations, especially considering that there is a gap between letter of RFC and actual behavior. Anyway, it only runs the check for "*/info/refs" GET request, which ends up in get_info_refs(). Other GET requests do not check CONTENT_LENGTH. Also, the version of service which is started from get_info_refs() do not consume input (I think, actually, the "--stateless-rpc" argument is not needed there).

> In any case, hopefully we can fix this before the final, as this is
> a regression introduced during this cycle?

Yes, I'm working on it.