Re: httpRange-14 Change Proposal

Noah,

As far as I can tell, the latest version of the relevant part of RFC2616bis is at [1] and contains the definition for 303 that is:

---
7.3.4 303 See Other

The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request, a user agent should perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.

This status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached independent of the original request.

A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such that the follow-on representation might be useful to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).

Except for responses to a HEAD request, the representation of a 303 response should contain a short hypertext note with a hyperlink to the Location URI.
---

Cheers,

Jeni

[1] https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#status.303

On 25 Mar 2012, at 22:53, Noah Mendelsohn wrote:

> 
> On 3/25/2012 5:15 PM, Jonathan A Rees wrote:
>> The baseline starts from HTTPbis, not 2616.
> 
> OK.
> 
> > I have confidence in HTTPbis. It is the wave of the future.
> 
> Yes, but I'm suggesting that the definition of 303 in HTTPbis should (maybe) clarify, but not incompatibly change the definition from RFC 2616.  FWIW, I see out there for HTTPbis [1] and [2]. I'm not expert in the ways of IETF, but as best I can tell, [1] is the latest clean draft, and it says:
> 
> "10.3.4 303 See Other
> 
> The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
> 
> The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
> 
>    Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303."
> 
> That looks to me pretty close to what's in RFC 2616. There does appear to be an evolving next draft, with some comments from Roy and David Booth on what a revised description might say [2]. I can't quite decide whether I think Roy's proposal that "A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such that the follow-on representation may be useful without implying that that it adequately represents the previously requested resource." The first sentence I think is fine. The second one I can't decide whether I'd be more comfortable with "The Location URI indicates a resource that >MAY be< descriptive of..."
> 
> Anyway, I think we're agreed that what we're targeting is a story that builds on or helps to shape HTTPbis. My comments were intended to suggest that I don't think HTTPbis should stray too far from what RFC 2616 says about 303. YMMV.
> 
> Noah
> 
> [1] http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.html#status.303
> [2] http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-04.html#status.303
> 

-- 
Jeni Tennison
http://www.jenitennison.com

Received on Sunday, 25 March 2012 22:09:55 UTC