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
next prev parent 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.