On Thu, Oct 15, 2009 at 09:52:28AM -0700, Shawn O. Pearce wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html