public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce•org>
To: "H. Peter Anvin" <hpa@zytor•com>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: More on git over HTTP POST
Date: Sat, 2 Aug 2008 21:12:58 -0700	[thread overview]
Message-ID: <20080803041258.GE27465@spearce.org> (raw)
In-Reply-To: <48952B2E.3030209@zytor.com>

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

  reply	other threads:[~2008-08-03  4:14 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01 21:50 More on git over HTTP POST H. Peter Anvin
2008-08-02 20:57 ` Shawn O. Pearce
2008-08-02 21:00   ` Daniel Stenberg
2008-08-02 21:08     ` Shawn O. Pearce
2008-08-02 21:23       ` Petr Baudis
2008-08-02 21:32         ` Shawn O. Pearce
2008-08-03  2:56   ` Shawn O. Pearce
2008-08-03  3:27     ` Junio C Hamano
2008-08-03  3:31       ` Shawn O. Pearce
2008-08-03  3:47       ` H. Peter Anvin
2008-08-03  4:10         ` Shawn O. Pearce
2008-08-03  8:10           ` david
2008-08-03 11:42             ` H. Peter Anvin
2008-08-03 11:29           ` H. Peter Anvin
2008-08-03  3:51     ` H. Peter Anvin
2008-08-03  4:12       ` Shawn O. Pearce [this message]
2008-08-03 11:31         ` H. Peter Anvin
2008-08-03  4:01     ` H. Peter Anvin
2008-08-03  6:43     ` Mike Hommey
2008-08-03  7:25     ` [RFC 1/2] Add backdoor options to receive-pack for use in Git-aware CGI Shawn O. Pearce
2008-08-03  7:25       ` [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport Shawn O. Pearce
2008-08-03 11:38         ` H. Peter Anvin
2008-08-03 21:25           ` Shawn O. Pearce
2008-08-03 22:16         ` Junio C Hamano
2008-08-04  3:59           ` Shawn O. Pearce
2008-08-04  9:53             ` Rogan Dawes
2008-08-04 10:08               ` Johannes Schindelin
2008-08-04 10:14                 ` Rogan Dawes
2008-08-04 10:26                   ` Johannes Schindelin
2008-08-04 14:48               ` Shawn O. Pearce
2008-08-04 15:45                 ` Rogan Dawes
2008-08-04 15:59                   ` Shawn O. Pearce
2008-08-04 16:18                     ` Rogan Dawes
2008-08-05  1:03                 ` H. Peter Anvin
2008-08-05  1:24                   ` Shawn O. Pearce
2008-08-05  1:35                     ` H. Peter Anvin
2008-08-05  1:57                       ` Shawn O. Pearce
2008-08-05  2:02                         ` H. Peter Anvin
2008-08-13  1:56                           ` H. Peter Anvin
2008-08-13  2:37                             ` Shawn O. Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080803041258.GE27465@spearce.org \
    --to=spearce@spearce$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    --cc=hpa@zytor$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox