On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote: > Max Kirillov <m...@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.
