On Tue, Sep 11, 2018 at 11:15:13AM -0700, Junio C Hamano wrote: > > That said, a quick search of codesearch.debian.net mostly finds > > examples using straight comparison, so maybe the patch is fine as-is. > > 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. 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. -Peff
