From: Tay Ray Chuan <rctay89@gmail.com>
To: "Git Mailing List" <git@vger.kernel.org>
Cc: "Junio C Hamano" <gitster@pobox.com>
Subject: [PATCH 12/14] reduce confusion over smart server response behaviour
Date: Wed, 11 Sep 2013 01:07:56 +0800 [thread overview]
Message-ID: <1378832878-12811-13-git-send-email-rctay89@gmail.com> (raw)
In-Reply-To: <1378832878-12811-12-git-send-email-rctay89@gmail.com>
The MUST and the following 'If' scenario may seem contradictory at first
glance; swap their order to alleviate this.
Also mention that the response should specifically be for the requested
service, for clarity's sake.
Based on:
From: Junio C Hamano <gitster@pobox.com>
Message-ID: <7vskdss3ei.fsf@alter.siamese.dyndns.org>
> +Smart Server Response
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +Smart servers MUST respond with the smart server reply format.
> +If the server does not recognize the requested service name, or the
> +requested service name has been disabled by the server administrator,
> +the server MUST respond with the '403 Forbidden' HTTP status code.
This is a bit confusing.
If you as a server administrator want to disable the smart upload-pack for
one repository (but not for other repositories), you would not be able to
force smart clients to fall back to the dumb protocol by giving "403" for
that repository.
Maybe in 2 years somebody smarter than us will have invented a more
efficient git-upload-pack-2 service, which is the only fetch protocol his
server supports other than dumb. If your v1 smart client asks for the
original git-upload-pack service and gets a "403", you won't be able to
fall back to "dumb".
The solution for such cases likely is to pretend as if you are a dumb
server for the smart request. That unfortunately means that the first
sentence is misleading, and the second sentence is also an inappropriate
advice.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Documentation/technical/http-protocol.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index 4bb1614..63a089a 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -234,12 +234,13 @@ description of the dumb server response.
Smart Server Response
^^^^^^^^^^^^^^^^^^^^^
-Smart servers MUST respond with the smart server reply format.
-
If the server does not recognize the requested service name, or the
requested service name has been disabled by the server administrator,
the server MUST respond with the '403 Forbidden' HTTP status code.
+Otherwise, smart servers MUST respond with the smart server reply
+format for the requested service name.
+
Cache-Control headers SHOULD be used to disable caching of the
returned entity.
--
1.8.4.rc4.527.g303b16c
next prev parent reply other threads:[~2013-09-10 17:09 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
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 ` Tay Ray Chuan [this message]
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=1378832878-12811-13-git-send-email-rctay89@gmail.com \
--to=rctay89@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).