Re: Question about the On Linking Alternative Representations TAG Finding

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

Received on Thursday, 31 July 2008 21:00:18 UTC