Re: Question about the On Linking Alternative Representations TAG Finding

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