- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 31 Jul 2008 17:35:16 -0400
- To: "T.V Raman" <raman@google.com>
- CC: tthibodeau@openlinksw.com, connolly@w3.org, richard@cyganiak.de, seb@serialseb.com, www-tag@w3.org
T.V Raman wrote: > 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? > Raman, kidehen$ curl -I -H "Accept: text/html" http://www.w3.org/People/Berners-Lee/card HTTP/1.1 406 Not Acceptable Date: Thu, 31 Jul 2008 21:17:53 GMT Server: Apache/2 Alternates: {"card.rdf" 0.9 {type application/rdf+xml} {length 18767}}, {"card.n3" 0.89 {type text/rdf+n3} {length 15285}} Vary: negotiate,accept TCN: list Connection: close Content-Type: text/html; charset=iso-8859-1 My user agent would understand either nice and clear i.e. make a decision about what's on offer :-) Now I don't want to believe that not having an extension (re "card") changes the essence of my point (or Ted's). A resource extension cannot be the final determinant of the resource type. Kingsley > 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 > > -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President & CEO OpenLink Software Web: http://www.openlinksw.com
Received on Thursday, 31 July 2008 21:35:53 UTC