- From: Nathan <nathan@webr3.org>
- Date: Fri, 07 Dec 2012 13:03:38 +0000
- To: Henry Story <henry.story@bblfish.net>
- CC: Ted Thibodeau Jr <tthibodeau@openlinksw.com>, Kingsley Idehen <kidehen@openlinksw.com>, public-webid@w3.org
Henry Story wrote: > People who do real implementations of Linked Data in javascript > on the browser are telling us this is problematic for them: speed > matters in user interface, and the 303 is creating real usability > issues. To keep this simple: 303 responses by RFC 2616 are not cache'd httpbis doesn't speak of caching in regard to 303 any more Pretty much all HTTP tooling everywhere for the last decade has used 2616 and will continue to for quite some time, 303's you may as well assume are not cache'd by clients (*clients = HTTP CLIENTS*). The web of linked data utilizes 303 redirects frequently, they are an every day part of what we do and encounter, any tooling which doesn't cater for them is missing half of the data out there. Every HTTP URI, with or without a fragment, can send back any status code, including 303, and could easily result in a huge chain of redirects. That is to say, WebID cannot preclude 303 responses, it's none of it's concern. WebID is layered on to HTTP, and the dereferencing process never has a fragment in it, so you're never dealing with a fragment at HTTP level. #frag URIs are great in linked data, very efficient and they keep things clean and simple. Slash-303 URIs exist and can be (and are) used. WebID Protocol requires no extra steps to enable their usage, in-fact it requires many many extra steps to try and preclude them. Ultimately we either say that a webid is an HTTP URI, or an HTTP URI with a Fragment - the latter restriction is virtually impossible to impose, but very easy to promote as a KISS approach to WebID w/ Linked Data.
Received on Friday, 7 December 2012 13:04:15 UTC