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

On 2/17/13 8:13 AM, Henry Story wrote:
>
> 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.

If you need to retrieve the data the describes the entity denoted by the 
Linked Data URI. Likewise, when you try to retrieve data that describes 
a specific entity denoted by a hash HTTP URI you end up retrieving the 
description of the entity and the description its descriptor i.e., the 
content retrieved is a combination of the document subject and the 
document itself.

Whenever you move from the theoretical to the practical by making a 
Linked Data browser (or something like that) you'll see the futility in 
your argument, until then I leave you to continue deflecting by 
references to specs etc..

If I recall, you mantra to other used to be go write an application re. 
WebID. Now you are on the receiving end of the same request from me re. 
Linked Data, and you simply won't do it. I am giving you every 
motivation to go prove me wrong!
>
> Henry
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen