Re: httpRange-14 Change Proposal

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

Received on Sunday, 25 March 2012 21:53:45 UTC