git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).