Re: (Dis)Proving that 303s have a performance impact.

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 

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).
] ]

So this makes quite clear that one needs to make a second GET.


Social Web Architect

Received on Sunday, 17 February 2013 13:13:47 UTC