- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Sun, 25 Mar 2012 17:53:17 -0400
- To: Jonathan A Rees <rees@mumble.net>
- CC: Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org List" <www-tag@w3.org>, public-lod community <public-lod@w3.org>
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