Re: More on git over HTTP POST

"H. Peter Anvin" [off-list ref] wrote:

Junio C Hamano wrote:

quoted

 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.

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.

-- 
Shawn.