- From: Henry Story <henry.story@bblfish.net>
- Date: Sun, 17 Feb 2013 14:13:16 +0100
- To: Adrian Gschwend <ktk@netlabs.org>
- Cc: "<public-webid@w3.org>" <public-webid@w3.org>
- Message-Id: <B458F38B-58E4-4F21-8503-E63267369842@bblfish.net>
On Sun 2013-Feb-17, at 11:22, Adrian Gschwend wrote: > Why on earth do I *have* to do 303 redirects in the second version? If > the client does proper content-negotiation I simply give him RDF back on > the first request. > On 17.02.13 13:45, Mo McRoberts wrote: > > >> Because if you don't do either of a hash nor a 303, you're using the >> same URI to describe both the document and the person "joe" described >> by that document. In practice, this means that you'll probably have >> no way to refer to "the document which describes joe". >> >> (Bear in mind the discussion revolves around the WebID URI, rather >> than the specific URI used on the wire in the request to the server, >> which will always be hashless) > > ah ok that clarifies it, thanks! Thanks Andrian for the question, thanks Mo for your answer. In the end I would be still not totally convinced by that answer though. I find answers that base themselves on established spec text to be more convincing, and go a lot further to establish a position. So I would argue from the HTTP1.1 spec ( RFC2616 ) which states in the section on 303 [[ 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). ] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4 ] So this makes quite clear that one needs to make a second GET. Henry Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Sunday, 17 February 2013 13:13:47 UTC