On Sat, 2 Aug 2008, Shawn O. Pearce wrote:

quoted text
> 
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>> Junio C Hamano wrote:
>>>  For example, putting them [capabilities] on extra HTTP headers is probably Ok.
>>
>> I think that would be a mistake, just because it's one more thing for
>> proxies to screw up on.
>
> I didn't realize we were in an era of proxies that are that
> brain-damaged that they cannot relay the other headers.  The Amazon
> S3 service relies heavily upon their own extended headers to make
> their REST API work.  If proxies stripped that stuff out then the
> client wouldn't work at all.
>
> IOW I had thought we were past this dark age of the Internet.

actually, it's not just a matter of not getting 'past this dark age of the 
Internet', it's an issue that so many people are tunneling _everyting_ 
over http (including the bad guys tunneling malware) that proxies are 
getting more aggressive then they have ever been before in pulling apart 
the payload and analysing it before letting it get through to the far 
side.

David Lang

quoted text
>> It's better to have negotiation information in
>> the payload, before the "real" data.
>
> I guess I could do that.  At least for the really complex stuff.
>
>> Obviously one thing that needs to be included in each transaction is a
>> transaction ID that will be reported back on the next transaction, since
>> you can't rely on a persistent connection.
>
> No.  That requires the server to maintain state.  We don't want to
> do that if we can avoid it.  I would much rather have the clients
> handle the state management as it simplifies the server side,
> especially when you start talking about reverse proxies and/or
> load-balancers running in front of the server farm.
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html