Re: More on git over HTTP POST

["Shawn O. Pearce" <spearce@spearce.org>]

"H. Peter Anvin" <hpa@zytor.com> 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.