Thread (3 messages) flat view 3 messages, 2 authors, 2018-09-09

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

From: Max Kirillov <hidden>
Date: 2018-09-08 05:41:14

On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote:
Max Kirillov [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help