Re: [RFC PATCH 1/4] Document the HTTP transport protocol

On Thu, Oct 15, 2009 at 09:52:28AM -0700, Shawn O. Pearce wrote:

quoted

And I can see it being useful for sites like github
which already have a cookie-based login.

What I'm concerned about is using the cookie jar.  My Mac OS X
laptop has 5 browsers installed, each with their own #@!*! cookie
jar: Safari, Opera, Firefox, Camino, Google Chrome.  How the hell
is the git client going to be able to use those cookies in order
to interact with a website that requires cookie authentication?

Sure, it is obviously something that an implementation will have to deal
with. Either through manual configuration by the user or some
auto-detection magic that tries to cover every case (and I suspect if we
really wanted to do this, a patch to libcurl to handle different cookie
jar formats would probably be the best way to go).

But my main point was that it is an implementation issue, not a protocol
issue. The lines are a little blurry for us because there really aren't
very many git implementations, but I think your document is an attempt
to document just the protocol to allow interoperability between clients.

But I think you got my point:

Not technical, but I want to reduce the amount of complexity that
a conforming client has to deal with to reduce support costs for
everyone involved.

I weakend the sections on cookies:

+ Authentication
+ --------------
....
+ Servers SHOULD NOT require HTTP cookies for the purposes of
+ authentication or access control.

and that's all we say on the matter.  I took out the Servers MUST
NOT line under session state.

I think this is a good compromise. It's not recommended at this point,
but there is no reason to disallow it if both sides can handle the
non-protocol part (i.e., storing and managing cookies). Thanks.

-Peff