Re: HTTP Link Header

Hello Lisa,

Other TAG members asked me to follow up on the brief conversation that  
we had in June about 303 responses. I hope you don't mind that I am  
cc:'ing the www-tag list - this will help maintain a record.

The subject was: Would will be willing to generate 303  
redirects for relation URIs, and why should it?

At the risk of being pedantic, I'll re-tell the story - you probably  
know all this, but I hope you will bear with me since it's the least  
confusing way I have of answering your last email (June 3).

In draft-nottingham-http-link-header-02 (from July) [1], a URI such as 
  is meant to name a relation (in RDFese, a "property"). There is no  
clear permission in RFC2616 to generate a 200 response in this  
situation, and RFC2616 seems to imply that a 200 response provides an  
entity that either *is* the resource itself or is something that can  
be substituted for it (a "representation" or "variant" of it). In  
either case the 200 seems to say that the resource is a document,  
which in this case is not true.

So to avoid the conclusion that some URI names a document, what people  
have started to do is deliver 303 redirects instead of 200 responses.  
This practice (which does not imply that the resource is *not* a  
document, but only does a dance to avoid the implication that it *is*)  
is codified in the TAG's httpRange-14 resolution [2].

The people who care about this - basically the semantic web community,  
the TAG, and probably some others - are going to want the server(s)  
delivering responses for  
to avoid 200s, preferably by using 303 or a 307 to a different server  
that in turn delivers a 303. The question is whether those managing 
  will be willing to do this. I do not pretend to take a position on  
whether they should - I just wanted to say why they would do it, if  
they wanted to.

(IIRC version 02 of the link header draft differs on the choice of  
relation URI compared to version 01 - if the URIs were of the form 
  then indeed there would be no issue around what should  
do. The switch from # to / was in progress when we spoke, but was yet  
not captured by a draft.)



(Tracker, this is ACTION-184)

Received on Thursday, 13 November 2008 19:23:41 UTC