Re: More on git over HTTP POST

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 3, 2008, 04:12 UTC
Message-ID: <20080803041258.GE27465@spearce.org>
In-Reply-To: <48952B2E.3030209@zytor.com>

"H. Peter Anvin" <hpa@zytor.com> wrote:

Show 12 quoted lines

> 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.