Re: 303 and HTTPbis

On 2/22/13 10:03 AM, Ted Thibodeau Jr wrote:
> On Feb 20, 2013, at 10:37 AM, Henry Story wrote:
>
>> But this makes clear that even for HTTPBis there are still two HTTP Connections required to get from a non hash WebID to a WebID Profile:
>>
>> 1. The first GET on the WebID returns a 303 with a Location header
>> 2. The second GET on the Location retrieves the Profile Document
>>
>> This means that the advantage of 303s with respect to caching of the content of 303s goes only so far as to allow a client to cache a 303 header (which means that the time to live of the redirect for example makes some sense) But the main inefficiency of redirects still remains. Even SPDY could not resolve this problem.
>
>
> *Except* that the 303 redirect followed by a second GET is
> *not required*.
>
> The server *may* return a 200 OK with appropriate HTTP headers
> and such, which indicate that the original GET isn't being
> returned, but the closest matching thing is -- and expressing
> the URI and MIME type of that closest matching thing -- thereby
> saving the second GET by pre-emptively delivering its result.
>
> If absolutely necessary, I'll invest the time in scouring the
> specs for where this is discussed -- but it's already been done
> several times in several other groups, and I assure you, this
> is there.
>
> Regards,
>
> Ted

Ted,

In addition to the above:
This is the about old internal redirect pattern which we implemented at 
the onset of our Linked Data product development i.e., instead of 
sending a 303 we used an internal redirect that lead to a 200 OK.

The issue outlined above re-emerged as a suggestion by Ian Davis as part 
of Toucan episode [1].

The only way to discuss this matter properly is for the topic itself to 
be correct i.e., not about mechanics, but the fundamental concept of 
indirection (implicit and explicit) as utilized by Linked Data.

As I've said before, Linked Data is nuance laced, productive discussion 
requires good implementation and/or utilization experience. When making 
a Linked Data based spec, the most productive path lies in sticking to 
the guidelines of TimBL's original Linked Data meme.

Conclusion:

We can stick to TimBL's original Linked Data meme (as opposed to 
misinterpreted comments about specific choices made in Tabulator's 
implementation) and negate distractions about Linked Data solution 
implementation details. I don't find it prudent to incorporate Linked 
Data learning-curve-inertia into the construction of the WebID and 
WebID+TLS specs, especially when its completely avoidable.

A Linked Data application (consumer or publisher) can use a variety of 
heuristics to negate the perceived costs of 303's.

Links:

1. http://lists.w3.org/Archives/Public/public-lod/2010Nov/0013.html -- 
is 303 really necessary ?
2. http://lists.w3.org/Archives/Public/public-lod/2010Nov/subject.html 
-- the whole thing which dominated the list during the month of 
November, 2010.

>
>
>
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
>
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                               //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>           10 Burlington Mall Road, Suite 265, Burlington MA 01803
>       Weblog   -- http://www.openlinksw.com/blogs/
>       LinkedIn -- http://www.linkedin.com/company/openlink-software/
>       Twitter  -- http://twitter.com/OpenLink
>       Google+  -- http://plus.google.com/100570109519069333827/
>       Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
>
>
>
>
>
>


-- 

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