Re: httpRange-14 Change Proposal

You were looking at a very old version. See the third paragraph of
section 7.3.4 at
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#page-32

Jonathan

On Sun, Mar 25, 2012 at 5:53 PM, Noah Mendelsohn <nrm@arcanedomain.com> 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

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