Re: [PATCH] http-backend: allow empty CONTENT_LENGTH
- Date: Sat, 8 Sep 2018 08:41:05 +0300
- From: Max Kirillov <max@xxxxxxxxxx>
- Subject: Re: [PATCH] http-backend: allow empty CONTENT_LENGTH
On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote:
> Max Kirillov <max@xxxxxxxxxx> 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
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.