Re: Is 303 really necessary?

On Sat, 2010-11-27 at 15:24 -0500, Tim Berners-Lee wrote: 
> Sorry, this thread has been around but the public-lod list 
> snuck up on me without my getting on it, so I have missed
> some of the fray!
> 
> 
> I am happy to look at improvements in the current HTTPRange 14
> architecture as I know that 303 is a pain.  But I don't want to break
> the web.
> 
> 
> Looking at http://bnb.bibliographica.org/entry/GB8102507
> the tabulator concludes that the thing identified by it
> is both a book and an RDF document, and it shows me, by default,  the
> triples it contains
> instead of the information about it, because that is what as a user I
> want.
> 
> 
> It doesn't use this new idea from IanD of using the content-location
> header as
> flag to indicate that the URI you used in the GET request may NOT be
> used
> to refer to the document returned.
> 
> 
> Suppose we go along with this new idea.
> 
> 
> Then, it will end up with  (ignoring namespaces) in N3 the information
> we get from that fetch includes:
> 
> 
> <http://bnb.bibliographica.org/entry/GB8102507> a Book;
> contributor [name "Boyd, William"].
> 
> 
> <http://bnb.bibliographica.org/entry/GB8102507.rdf> a DataDocument;
> foaf:primaryTopic <http://bnb.bibliographica.org/entry/GB8102507>.
> 
> 
> Ok,  I understand the system. 
> 
> 
> But if you introduce this as the architecture of the  web, 
> then it applies all the time.  You can't chose when it applies and
> when it doesn't.
> 
> 
> Now look at 
> 
> 
> http://www.w3.org/2008/site/images/logo-w3c-mobile-lg
> 
> 
> This dereferenced to give you a content-location of
> 
> 
> http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png
> 
> 
> What do we know then?
> 
> 
> <http://www.w3.org/2008/site/images/logo-w3c-mobile-lg.png>
> we know we can use to refer to the image in its PNG version.
> <http://www.w3.org/2008/site/images/logo-w3c-mobile-lg>
> we know nothing about.
> 
> 
> Because the fetch returned a content-location header,
> we are now not allowed to use that URI to refer to anything -- it
> could
> after all refer to the Eiffel Tour, or the W3C as an organization
> according to the new system.
> 
> 
> Does this make sense?
> 
> 
> If you look that up in a browser, you will see the image in the 
> window and the URI in the title bar.
> We in fact really expect that people SHOULD use the generic URI
> "http://www.w3.org/2008/site/images/logo-w3c-mobile-lg"
> to refer to the logo, not the .png URI, as people may need the
> content negotiation, and we may introduce a new version in
> a new graphics format some time.
> 
> 
> So all across the web, people are, and should use the original URI
> to refer to the image.  Tthey 
> see something in the URI bar and a document (image, etc)
> in the window and they assume rightly they can use that
> URI to refer to that image.
> 
> 
> The bookmarking system works like this.
> Emailing a friend a URI of something you are looking at works like
> this.
> Making a link to something you think it cool works like this.
> Putting a image in your page someone else has in their page works like
> this.
> The web works like this.
> 
> 
> We can't make the semantic web work in a way that actually
> leaves the web not working.
> 
> 
> We can't leave the WWW working one way and the LOD web
> working another, as they are inextricably interconnected.
> 
> 
> Now ....  Someone in the the thread somewhere at one point suggested a
> friendly
> amendment to the original proposal, where a new status code
> is sent for semantic web data being returned *about* the
> object identified by the request URI, rather than information *in* it.
> I think 208 was suggested, I.e, the next unused one.
> 
> 
> With that modification, I can't see a snag.
> 
> 
> - It is only used for data so old web browsers are not going to be
> seeing it
> - The data world is young enough for us to slide it in, maybe, without
> too much
>   harm to existing clients, which would all have to be recoded, but it
> might be worth it to 
> relieve this tension.
> - the rest of the web continue to use 200
> 
> 
> 
> 
> Tim
> 
> 

Hi Tim,

I think much of your argument against using 200 can be extended for
using any 200 series status code. Representations that merely describe a
resource (and don't completely represent it) cause ambiguity because Web
browsers today interpret all 200 series responses (from a GET request)
as containing an complete representation of the resource identified in
the request URL. Even though this behaviour is not in the spec, Web
browser behave this way today.

As you said, people (and browsers) use the URL in the address bar as an
identifier for the document below it (in GET requests). Even if tomorrow
the spec said responses with status code 208 do not represent the
resource identified in the GET request URL, it would leave today's
browsers not working. Furthermore, Web browser vendors would never agree
to show the Content-Location URL in the address bar due to
security/authority concerns.

Any solution that causes today's Web browsers to show a URL in the
address bar (from a GET request) which does not identify the document
below, "leaves the web not working".

I wrote more about this in a blog post:
http://jamesrdf.blogspot.com/2010/11/status-code-200-vs-303.html

Cheers,
James
-- 
James Leigh Services Inc.
http://www.leighnet.ca/
http://jamesrdf.blogspot.com/

Received on Monday, 29 November 2010 13:55:28 UTC