From: "Shawn O. Pearce" <spearce@spearce.org>
To: Mike Hommey <mh@glandium.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>,
git@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] Document the HTTP transport protocol
Date: Fri, 16 Oct 2009 07:21:35 -0700 [thread overview]
Message-ID: <20091016142135.GR10505@spearce.org> (raw)
In-Reply-To: <20091016071942.GC3009@glandium.org>
Mike Hommey <mh@glandium.org> wrote:
> On Thu, Oct 15, 2009 at 10:59:25PM -0700, H. Peter Anvin wrote:
> > On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote:
> > > On 2009-10-09, Junio C Hamano <gitster@pobox.com> wrote:
> > >>> +If there is no repository at $GIT_URL, the server MUST respond with
> > >>> +the '404 Not Found' HTTP status code.
> > >>
> > >> We may also want to add
> > >>
> > >> If there is no object at $GIT_URL/some/path, the server MUST respond
> > >> with the '404 Not Found' HTTP status code.
> > >>
> > >> to help dumb clients.
> > >
> > > In both cases - is it really necessary to forbid the use of 410 (Gone)?
My original text got taken a bit out of context here. I guess MUST
was too strong of a word. I more ment something like:
If there is no repository at $GIT_URL, the server MUST NOT respond
with '200 OK' and a valid info/refs response. A server SHOULD
respond with '404 Not Found', '410 Gone', or any other suitable
HTTP status code which does not imply the resource exists as
requested.
> > 410 means "we once had it, it's no longer here, no idea where it went."
> > It's a largely useless code...
>
> There is an additional meaning to it, that is "it will never ever
> return". It thus has a stronger meaning than 404. Sadly, not even search
> engine spiders consider it as a hint to not crawl there in the future...
I know. I broke a URL on a site back in Janurary, MSN keeps crawling
it anyway. F'king spiders.
--
Shawn.
next prev parent reply other threads:[~2009-10-16 14:25 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
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 [this message]
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=20091016142135.GR10505@spearce.org \
--to=spearce@spearce.org \
--cc=antti-juhani@kaijanaho.fi \
--cc=git@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=mh@glandium.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 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).