- From: T.V Raman <raman@google.com>
- Date: Thu, 31 Jul 2008 14:00:12 -0700
- To: tthibodeau@openlinksw.com
- Cc: connolly@w3.org, richard@cyganiak.de, raman@google.com, seb@serialseb.com, www-tag@w3.org, kidehen@openlinksw.com
Thanks for the excellent analsysis. Minor nit: I think you meant HTTP, rather than HTML in <cite> which must get an HTML result code. I think they are equally </cite> What do present-day user agents do when they get a 406? Ted Thibodeau Jr writes: > 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 -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Thursday, 31 July 2008 21:01:36 UTC