From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Eric Sunshine <sunshine@sunshineco.com>,
Derrick Stolee <stolee@gmail.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 0/4] Additional FAQ entries
Date: Fri, 05 Jul 2024 22:59:57 -0700 [thread overview]
Message-ID: <xmqqo77b3vs2.fsf@gitster.g> (raw)
In-Reply-To: <ZocS0NgiAbg5Mnzp@tapette.crustytoothpaste.net> (brian m. carlson's message of "Thu, 4 Jul 2024 21:23:28 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> Buffering the entire thing will break because ...? Deadlock? Or is
>> there anything more subtle going on?
>
> When we use the smart HTTP protocol, the server sends keep-alive and
> status messages as one of the data streams, which is important because
> (a) the user is usually impatient and wants to know what's going on and
> (b) it may take a long time to pack the data, especially for large
> repositories, and sending no data may result in the connection being
> dropped or the client being served a 500 by an intermediate layer. We
> know this does happen and I've seen reports of it.
And this is an example of "a proxy that buffers the data, without
modifying or tampering with, would still break transport"?
> We've also seen some cases where proxies refuse to accept
> Transfer-Encoding: chunked (let's party like it's 1999) and send a 411
> back since there's no Content-Length header.
This is "a proxy that wanted to buffer the data but failed to do so"
that ended up modifying the data Gits sitting at both ends of the
connection can observe, so it is a bit different issue. It clearly
falls into "modify or tampering with" category.
I forgot to say this clearly when I wrote the message you are
responding to, but I am trying to see if we can clarify the "or
buffer" part in "modify, tamper with, or buffer", as offhand I did
not think of a reason why a proxy would break the Git communication
if it receives a segment that was 2MB originally from upload-pack,
and forwards the contents of the segment in two 1MB segments without
tampering or modifying the payload bytes at all to fetch-pack.
Thanks.
next prev parent reply other threads:[~2024-07-06 5:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 0:38 [PATCH v3 0/4] Additional FAQ entries brian m. carlson
2024-07-04 0:38 ` [PATCH v3 1/4] gitfaq: add documentation on proxies brian m. carlson
2024-07-04 0:38 ` [PATCH v3 2/4] gitfaq: give advice on using eol attribute in gitattributes brian m. carlson
2024-07-04 5:22 ` Junio C Hamano
2024-07-04 21:10 ` brian m. carlson
2024-07-04 0:38 ` [PATCH v3 3/4] gitfaq: add entry about syncing working trees brian m. carlson
2024-07-04 5:21 ` Junio C Hamano
2024-07-04 21:08 ` brian m. carlson
2024-07-06 5:50 ` Junio C Hamano
2024-07-04 0:38 ` [PATCH v3 4/4] doc: mention that proxies must be completely transparent brian m. carlson
2024-07-04 1:25 ` [PATCH v3 0/4] Additional FAQ entries Junio C Hamano
2024-07-04 5:22 ` Junio C Hamano
2024-07-04 21:23 ` brian m. carlson
2024-07-06 5:59 ` Junio C Hamano [this message]
2024-07-08 0:52 ` brian m. carlson
2024-07-06 6:47 ` Jeff King
2024-07-06 17:18 ` Junio C Hamano
2024-07-09 23:37 ` [PATCH v4 " brian m. carlson
2024-07-09 23:37 ` [PATCH v4 1/4] gitfaq: add documentation on proxies brian m. carlson
2024-07-09 23:37 ` [PATCH v4 2/4] gitfaq: give advice on using eol attribute in gitattributes brian m. carlson
2024-07-09 23:37 ` [PATCH v4 3/4] gitfaq: add entry about syncing working trees brian m. carlson
2024-07-09 23:37 ` [PATCH v4 4/4] doc: mention that proxies must be completely transparent brian m. carlson
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=xmqqo77b3vs2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).