Re: [PATCH v3 0/4] Additional FAQ entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux