All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rogan Dawes <lists@dawes.za.net>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
Date: Mon, 04 Aug 2008 17:45:59 +0200	[thread overview]
Message-ID: <48972437.5050008@dawes.za.net> (raw)
In-Reply-To: <20080804144824.GB27666@spearce.org>

Shawn O. Pearce wrote:
> Rogan Dawes <lists@dawes.za.net> wrote:
>> Shawn O. Pearce wrote:
>>> 	Smart Server Detection
>>> 	----------------------
>>>
>>> 	To detect a smart (Git-aware) server a client sends an
>>> 	empty POST request to info/refs; [...]
>>>
>>> 		C: POST /repository.git/info/refs HTTP/1.0
>>> 		C: Content-Length: 0
>> I don't understand why you would want to keep the commands in the URL  
>> when you are doing a POST?
> 
> Well, as Dscho pointed out this partly has to do with caching and
> the transparent dumb server functionality.  By using the command in
> the URL, and having the command match that of the dumb server file,
> its easier to emulate a dumb server and also to permit caching.
> 
> Currently git-http-backend requests no caching for info/refs, but
> I could see us tweaking that to permit several minutes of caching,
> especially on big public sites like kernel.org.  Having info/refs
> report stale by 5 minutes is not an issue when writes to there
> already have a lag due to the master-slave mirroring system in use.

Fair enough, but what about the quote from RFC2616 that I posted in 
rebuttal to Dscho?

 > 13.10 Invalidation After Updates or Deletions
 >
 > ...
 >
 > Some HTTP methods MUST cause a cache to invalidate an entity. This is
 > either the entity referred to by the Request-URI, or by the Location
 > or Content-Location headers (if present). These methods are:
 >
 >       - PUT
 >       - DELETE
 >       - POST

This doesn't seem negotiable to me.

For those resources that are expected to be cacheable, the request 
should be made using a GET.

> Because git-http-backend emulates a dumb server there is a command
> dispatch table based upon the URL submitted.  Thus we already have
> the command dispatch behavior implemented in the URL and doing it
> in the POST body would only complicate the code further.

Not by a huge amount, surely?

if (method == "GET") command = ...
else if (method == "POST") command = ...
dispatch(command);

Rogan

  reply	other threads:[~2008-08-04 15:47 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01 21:50 More on git over HTTP POST H. Peter Anvin
2008-08-02 20:57 ` Shawn O. Pearce
2008-08-02 21:00   ` Daniel Stenberg
2008-08-02 21:08     ` Shawn O. Pearce
2008-08-02 21:23       ` Petr Baudis
2008-08-02 21:32         ` Shawn O. Pearce
2008-08-03  2:56   ` Shawn O. Pearce
2008-08-03  3:27     ` Junio C Hamano
2008-08-03  3:31       ` Shawn O. Pearce
2008-08-03  3:47       ` H. Peter Anvin
2008-08-03  4:10         ` Shawn O. Pearce
2008-08-03  8:10           ` david
2008-08-03 11:42             ` H. Peter Anvin
2008-08-03 11:29           ` H. Peter Anvin
2008-08-03  3:51     ` H. Peter Anvin
2008-08-03  4:12       ` Shawn O. Pearce
2008-08-03 11:31         ` H. Peter Anvin
2008-08-03  4:01     ` H. Peter Anvin
2008-08-03  6:43     ` Mike Hommey
2008-08-03  7:25     ` [RFC 1/2] Add backdoor options to receive-pack for use in Git-aware CGI Shawn O. Pearce
2008-08-03  7:25       ` [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport Shawn O. Pearce
2008-08-03 11:38         ` H. Peter Anvin
2008-08-03 21:25           ` Shawn O. Pearce
2008-08-03 22:16         ` Junio C Hamano
2008-08-04  3:59           ` Shawn O. Pearce
2008-08-04  9:53             ` Rogan Dawes
2008-08-04 10:08               ` Johannes Schindelin
2008-08-04 10:14                 ` Rogan Dawes
2008-08-04 10:26                   ` Johannes Schindelin
2008-08-04 14:48               ` Shawn O. Pearce
2008-08-04 15:45                 ` Rogan Dawes [this message]
2008-08-04 15:59                   ` Shawn O. Pearce
2008-08-04 16:18                     ` Rogan Dawes
2008-08-05  1:03                 ` H. Peter Anvin
2008-08-05  1:24                   ` Shawn O. Pearce
2008-08-05  1:35                     ` H. Peter Anvin
2008-08-05  1:57                       ` Shawn O. Pearce
2008-08-05  2:02                         ` H. Peter Anvin
2008-08-13  1:56                           ` H. Peter Anvin
2008-08-13  2:37                             ` Shawn O. Pearce

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=48972437.5050008@dawes.za.net \
    --to=lists@dawes.za.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hpa@zytor.com \
    --cc=spearce@spearce.org \
    /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.