Jeff King wrote:
> On Tue, Sep 11, 2018 at 11:15:13AM -0700, Junio C Hamano wrote:
>> 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.
>
> It's pretty common for Git to send gzip'd contents, so this might
> actually be necessary on day one. However, it looks like we do so by
> setting the content-encoding header.
Correct, we haven't been using Transfer-Encoding for that.
> I really wonder if this topic is worth pursuing further without finding
> a real-world case that actually fails with the v2.19 code. I.e., is
> there actually a server that doesn't set CONTENT_LENGTH and really can't
> handle read-to-eof? It's plausible to me, but it's also equally
> plausible that we'd be breaking some other case.
I wonder about the motivating IIS case. The CGI spec says that
CONTENT_LENGTH is set if and only if the message has a message-body.
When discussing message-body, it says
Request-Data = [ request-body ] [ extension-data ]
[...]
A request-body is supplied with the request if the CONTENT_LENGTH is
not NULL. The server MUST make at least that many bytes available
for the script to read. The server MAY signal an end-of-file
condition after CONTENT_LENGTH bytes have been read or it MAY supply
extension data. Therefore, the script MUST NOT attempt to read more
than CONTENT_LENGTH bytes, even if more data is available.
Does that mean that if CONTENT_LENGTH is not set, then we are
guaranteed to see EOF, because extension-data cannot be present? If
so, then what we have in v2.19 (plus Max's test improvement that is in
"next") is already enough.
So I agree.
1. Junio, please eject this patch from "pu", since we don't have any
need for it.
2. IIS users, please test v2.19 and let us know how it goes.
Do we have any scenarios that would use an empty POST (or other
non-GET) request?
Thanks,
Jonathan
