From: Shawn O. Pearce Date: Sun, 03 Aug 2008 04:12:58 GMT Subject: Re: More on git over HTTP POST Message-ID: <20080803041258.GE27465@spearce.org> In-Reply-To: <48952B2E.3030209@zytor.com> "H. Peter Anvin" wrote: > Shawn O. Pearce wrote: >> Chunked Transfer Encoding >> ------------------------- >> >> For performance reasons the HTTP/1.1 chunked transfer encoding is >> used frequently to transfer variable length objects. This avoids >> needing to produce large results in memory to compute the proper >> content-length. > > Note: you cannot rely on HTTP/1.1 being supported by an intermediate > proxy; you might have to handle HTTP/1.0, where the data is terminated > by connection close. Well, that proxy is going to be crying when we upload a 120M pack during a push to it, and it buffers the damn thing to figure out the proper Content-Length so it can convert an HTTP/1.1 client request into an HTTP/1.0 request to forward to the server. That's just _stupid_. But from the client side perspective the chunked transfer encoding is used only to avoid generating in advance and producing the content-length header. I fully expect the encoding to disappear (e.g. in a proxy, or in the HTTP client library) before any sort of Git code gets its fingers on the data. Hence to your other remark, I _do not_ rely upon the encoding boundaries to remain intact. That is why there is Git pkt-line encodings inside of the HTTP data stream. We can rely on the pkt-line encoding being present, even if the HTTP chunks were moved around (or removed entirely) by a proxy. -- Shawn.