Minor update to Cool URIs for SW

All,

One of the deliverables of the (now closed) SWEO IG was the IG Note  
“Cool URIs for the Semantic Web” [1]. It turns out that we made a  
small but important omission when writing the document. We want to fix  
this as a minor update to the document, and hereby seek feedback on  
the proposed change.


THE PROBLEM

According to RFC 2616, servers SHOULD send a Vary HTTP header with any  
response that was subject to content negotiation (that is, one of  
several representations was chosen based on client headers such as  
Accept) [2].

If a server doesn't do this, then caches in the middle can become  
confused and might send an unexpected response back to clients, e.g. a  
client that asks for RDF via the Accept header might get an HTML  
response because the HTML was cached in the middle, and the cache has  
no way of knowing that the server might generate a different response  
for a different Accept header.

This problem has been observed in practice by implementers that  
followed the recipes of the Cool URIs document. The issue is very hard  
to debug, because implementers might not even be aware of the cache in  
the middle. This is why we think that a note about this header should  
be added to the document.


PROPOSED CHANGE

Section 2.1 “HTTP and Content Negotiation” [3] contains the following  
example:

| HTTP/1.1 200 OK
| Content-Type: text/html
| Content-Language: en
| Content-Location: http://www.example.com/people.en.html

Add one line to the end:

| Vary: accept, accept-language

The section contains another example:

| HTTP/1.1 302 Found
| Location: http://www.example.com/people/alice.en.html

Again, add one line to the end:

| Vary: accept, accept-language

Add a new paragraph after the paragraph starting “Here we see Content  
negotiation [TAG-Alt] in action…” in the same section:

| The Vary header indicates which request headers were used by the  
server
| to select a representation. In the example, the server's response  
tells
| the client that sending a different Accept or Accept-Language header  
might
| have resulted in a different response. Knowing this is important for
| caches that might sit in the middle between server and client.

We seek feedback on this particular change -- do you see any problems  
with it, or can you suggest better wording?

Cheers,
Leo and Richard


[1] http://www.w3.org/TR/2008/NOTE-cooluris-20080331/
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
[3] http://www.w3.org/TR/2008/NOTE-cooluris-20080331/#conneg

Received on Wednesday, 12 November 2008 16:53:20 UTC