All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.