Re: Question about the On Linking Alternative Representations TAG Finding

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