W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: NEW ISSUE: Clarify whether request must be processed before responding with redirection codes

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 3 Jul 2013 13:31:08 -0700
Message-ID: <CABkgnnXnsp1Ca=EEDQ2XBoK0MH0RcLhzfCrq3Nge-=1A2tO9vg@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 3 July 2013 12:16, cowwoc <cowwoc@bbs.darktech.org> wrote:
> For each status code in the 300 range please clarify which HTTP methods are
> acceptable (e.g. is 304 acceptable for methods other than GET?) and whether
> the server MUST or MUST NOT process the request before responding with that
> code.

We just discussed a more general version of the same issue for
HTTP/2.0.  Whether the request has been processed or not is implicit
in the description of some of the codes.

For instance: 303 says:

   The response to the request can be found under a different URI and
   SHOULD be retrieved using a GET method on that resource.

That says to me that the response can be retrieved.  If the request
implies some action, and the only way to observe whether that action
has occurred is to GET the identified resource, then the exact time
that said action occurs need only be between receipt of the first (the
POST) request and the response to the redirected GET.  That allows
some freedom to servers that I'd be opposed to giving up.

If the results of the action can be observed in other ways, then those
ways need to be consistent with what the server has reported.  That is
entirely up to the server, though.

If there is a specific case where you believe this to be necessary,
because it creates an ambiguity, then by all means let us know.  My
read of the 3xx series says that only 303 has this potential for
interesting behavior.
Received on Wednesday, 3 July 2013 20:31:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC