From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] Document the HTTP transport protocol
Date: Thu, 15 Oct 2009 09:52:28 -0700 [thread overview]
Message-ID: <20091015165228.GO10505@spearce.org> (raw)
In-Reply-To: <20091009195035.GA15153@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Oct 08, 2009 at 10:22:45PM -0700, Shawn O. Pearce wrote:
> > +Servers MUST NOT require HTTP cookies for the purposes of
> > +authentication or access control.
> > [...]
> > +Servers MUST NOT require HTTP cookies in order to function correctly.
>
> Why not? I can grant that the current git implementation probably can't
> handle it, but keep in mind this is talking about the protocol and not
> the implementation.
Good point... this document is about trying to explain the common
functionality that everyone can agree on.
> 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?
> Adapting the client to handle
> this case would not be too difficult (it would just mean keeping cookie
> state in a file between runs,
Saving our own cookie jar is easy, libcurl has some limited cookie
jar support already built in. We just have to enable it.
> or even just pulling it out of the normal
> browser's cookie store).
See above, I don't think this will be very easy.
> And people whose client didn't do this would
> simply get an "access denied" response code.
And then they will email git ML or ask on #git why their git client
can't speak to some random website... and its because they used
"lynx" or yet-another-browser whose cookie jar format we can't read.
> Is there a technical reason not to allow it?
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.
--
Shawn.
next prev parent reply other threads:[~2009-10-15 17:01 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-09 5:22 [RFC PATCH 0/4] Return of smart HTTP Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 1/4] Document the HTTP transport protocol Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 2/4] Git-aware CGI to provide dumb HTTP transport Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 3/4] Add smart-http options to upload-pack, receive-pack Shawn O. Pearce
2009-10-09 5:22 ` [RFC PATCH 4/4] Smart fetch and push over HTTP: server side Shawn O. Pearce
2009-10-09 5:52 ` [RFC PATCH 2/4] Git-aware CGI to provide dumb HTTP transport J.H.
2009-10-09 8:01 ` [RFC PATCH 1/4] Document the HTTP transport protocol Sverre Rabbelier
2009-10-09 8:09 ` Sverre Rabbelier
2009-10-09 8:54 ` Alex Blewitt
2009-10-15 16:39 ` Shawn O. Pearce
2009-10-09 19:27 ` Jakub Narebski
2009-10-09 19:50 ` Jeff King
2009-10-15 16:52 ` Shawn O. Pearce [this message]
2009-10-15 17:39 ` Jeff King
2009-10-09 20:44 ` Junio C Hamano
2009-10-10 10:12 ` Antti-Juhani Kaijanaho
2009-10-16 5:59 ` H. Peter Anvin
2009-10-16 7:19 ` Mike Hommey
2009-10-16 14:21 ` Shawn O. Pearce
2009-10-16 14:23 ` Antti-Juhani Kaijanaho
2010-04-07 18:16 ` Tay Ray Chuan
2010-04-07 18:19 ` Tay Ray Chuan
2010-04-07 19:11 ` (resend v2) " Tay Ray Chuan
2010-04-07 19:51 ` Junio C Hamano
2010-04-08 1:47 ` Tay Ray Chuan
2010-04-07 19:24 ` Tay Ray Chuan
2009-10-10 12:17 ` Tay Ray Chuan
2010-04-06 4:57 ` Scott Chacon
2010-04-06 6:09 ` Junio C Hamano
[not found] ` <u2hd411cc4a1004060652k5a7f8ea4l67a9b079963f4dc4@mail.gmail.com>
2010-04-06 13:53 ` Scott Chacon
2010-04-06 17:26 ` Junio C Hamano
2013-09-10 17:07 ` [PATCH 00/14] document edits to original http protocol documentation Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 01/14] Document the HTTP transport protocol Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 02/14] normalize indentation with protcol-common.txt Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 03/14] capitalize key words according to RFC 2119 Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 04/14] normalize rules with RFC 5234 Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 05/14] drop rules, etc. common to the pack protocol Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 06/14] reword behaviour on missing repository or objects Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 07/14] weaken specification over cookies for authentication Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 08/14] mention different variations around $GIT_URL Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 10/14] fix example request/responses Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 11/14] be clearer in place of 'remote repository' phrase Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 12/14] reduce confusion over smart server response behaviour Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 13/14] shift dumb server response details Tay Ray Chuan
2013-09-10 17:07 ` [PATCH 14/14] mention effect of "allow-tip-sha1-in-want" capability on git-upload-pack Tay Ray Chuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091015165228.GO10505@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).