- 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