Re: [PATCH] http-backend: treat empty CONTENT_LENGTH as zero

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux