- From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Date: Thu, 31 Jul 2008 16:46:50 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: Richard Cyganiak <richard@cyganiak.de>, "T.V Raman" <raman@google.com>, seb@serialseb.com, www-tag@w3.org, kidehen@openlinksw.com
All -- * Dan Connolly [7/31/08 12:12 PM -0500] wrote: > On Thu, 2008-07-31 at 17:43 +0100, Richard Cyganiak wrote: >> >> Let's say I have >> >> /resource (generic information resource with HTML and JSON >> variants) >> /resource.html (a HTML specific URI) >> /resource.json (a JSON specific URI) >> >> Now let's say I request /resource.json with an Accept header of >> "Accept: text/html". What should happen? >> >> One opinion is that the JSON should be served anyway, because >> the URI identifies a specific variant. >> >> Another opinion is that the HTML should be served, or redirected >> to, because that's what the client asked for and the server has >> it available. >> >> (A third opinion is that 406 should be answered, as suggested by >> Sebastien.) > > Either a 406 or a 200 with JSON is consistent with the > claim that /resource.json is JSON-specific. > Serving a 200 with text/html is not. > > A redirect might be reasonable... it feels like a bit of a stretch. In what I hope are simplest terms, the following from RFC 2616 [2] -- If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response. I believe the above should take precedence over the TAG page, if they are perceived to be in conflict. It should certainly bring clarity, as I do not believe they do conflict. If the above doesn't provide enough clarity, then we must analyze all relevant scenarios, to gain that clarity. Starting from the generics above, we have 3 resources (three? yes! [1]) -- /foo (generic information resource with HTML and JSON variants) /foo.1 (an HTML specific URI -- the HTML variant) /foo.2 (a JSON specific URI -- the JSON variant) -- and 3 Accept: header values -- (no header) text/html application/json (Note -- I'm using "foo.1" where Richard used "resource.html", because the filename/URI should play *no* part in either server or agent determination of its filetype -- if anything, it's a hint in absence of MIME type, but we *have* MIME type in this discussion.) First -- what of the scenarios with *no* Accept: header? I think they are fairly straightforward, especially in light of the RFC snippet above -- Request \\ Accept: || ======================================================== /foo || 300 text/html = /foo.1 ; || application/json = /foo.2 || /foo.1 || 200 OK /foo.1 || /foo.2 || 200 OK /foo.2 I'm presuming that foo.1 and foo.2 are considered interchangeable, that neither is the "default" form of the resource. If one *is* the "default" form, say /foo.1, then the 300 above should be replaced with 200 OK /foo.1 VARY [3]. That leaves us 6 request scenarios with Accept: headers, each of which must get an HTML result code. I think they are equally straightforward as the above -- \\ Accept: || | \\ value || | Request \\ || text/html | application/json ============================================================= /foo || 302 /foo.1 | 302 /foo.2 || or 200 OK /foo.1 VARY | or 200 OK /foo.2 VARY || | /foo.1 || 200 OK /foo.1 | 406 text/html || | = /foo.1 /foo.2 || 406 application/json | || = /foo.2 | 200 OK /foo.2 *IF* the server is aware that /foo.1 and /foo.2 are variations of /foo -- then both 406 responses in this table should include both resources and formats, as the 300 did above -- 406 text/html = /foo.1 ; application/json = /foo.2 >From RFC 2616 [3] -- 10.4.7 406 Not Acceptable The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions. The "Note" here is what lets the server send JSON when it were asked for HTML, and vice versa, but I submit that permission does not equal instruction, and that this Note SHOULD have been written to say "HTTP/1.1 servers SHOULD NOT but MAY..." The last paragraph is what happens when your browser doesn't know how to handle the MIME type it's given -- e.g., when your browser is given application/json but only knows how to cope with text/html. It seems worthwhile to include the following from RFC 2119 [4] -- 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I submit that the full implications have not been understood, if another course *has* been chosen. >> What I'm asking for is simply a clarification of the advice >> in the spec. Did you intend that there be content negotiation >> on the representation_i URIs? > > I didn't; re-reading the text, I don't see any other way > to read it. > > http://www.w3.org/2001/tag/doc/alternatives-discovery.html [1] Some would say that /resource.html and /resource.json are "just" representations of /resource -- but I am of the opinion that they are Resources in their own right, not least because they *have* their own URIs. "The Map is not the Territory." Likewise, a representation of a Resource is not that Resource -- but it is *a* Resource. [2] http://www.rfc.net/rfc2616.html#s14.1 [3] I'm using VARY as shorthand to indicate a VARY response header which must contain all relevant headers used to generate that response, as called for (once more) by RFC 2616. [4] http://www.rfc.net/rfc2616.html#s10.4.7 [5] http://rfc.net/rfc2119.html -- 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 Evangelism & Support // mailto:tthibodeau@openlinksw.com OpenLink Software, Inc. // http://www.openlinksw.com/ http://www.openlinksw.com/weblogs/uda/ OpenLink Blogs http://www.openlinksw.com/weblogs/virtuoso/ http://www.openlinksw.com/blog/~kidehen/ Universal Data Access and Virtual Database Technology Providers
Received on Thursday, 31 July 2008 21:00:18 UTC