Hello,
As I noted in email yesterday:
> Personally, from a quick read of [2], I am not clear on its
> relationship to [1], which seems to already describe how an HTTP
> server and user-agent may, in concert, enable discovery by the client
> of alternate representations of a resource.
>
> - johnk
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
> [2] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
I saw no reference in the document under discussion to a document which
seems to document a solution to the issue of discovering alternative
resources.
Since others on this list have also mentioned the use of HTTP 1.1 300
status, and the return of a list of alternative links, is there any
intent to update [2] to reference the work on content negotiation
described in RFC 2616?
I would also note that the HTTP Link: header [A]
, and the <link/> element of Atom may now be relevant to this discussion
too.
Regards,
- johnk
[A] http://tools.ietf.org/html/draft-nottingham-http-link-header-02
Forwarded message 1
ext Richard Cyganiak wrote:
>
> Raman,
>
> My question was not at all about HTML vs. XHTML, Sebastien injected that
> angle into the thread in a somewhat unhelpful way. I'm not interested in
> hearing yet more people's opinions on the issue. I ask for clarification
> of a detail in the TAG finding because I'm not sure how to interpret the
> finding's intention.
>
> 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.
HTTP 1.1 allows the server to choose (see [1]) with "Server-driven
negotiation". It can use as input not only the HTTP headers supplied,
but also the hint supplied in the URI path.
Or, the server can choose to return an HTTP 300 or 406 response, and a
list of alternate representations allowing the user-agent to choose
(so-called "agent-driven" negotiation).
And there is the option of a combination of the two - so-called
"transparent" negotiation.
>
> 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.)
>
> 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?
Personally, from a quick read of [2], I am not clear on its relationship
to [1], which seems to already describe how an HTTP server and
user-agent may, in concert, enable discovery by the client of alternate
representations of a resource.
- johnk
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
[2] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
>
> Cheers,
> Richard
>
>
> On 31 Jul 2008, at 17:21, T.V Raman wrote:
>
>>
>>
>> I'm a bit confused at this point by the question.
>>
>> Could you flesh out your example?
>>
>> HTML is a particularly good example, depending on how much you
>> know about your HTML resource.
>>
>> Though there is much debate on this, in my experience,
>> wel--formed XHTML survives well when served either as text/html
>> or application/xml+xhtml.
>>
>> So if you have a resource under your control whose content you
>> know is well-formed XHTML that you would rather serve as
>> application/xml+xhtml, but you also know that many legacy agents
>> only accept text/html
>> In that case, you might definitely want to check the accept
>> header and serve the appropriate response.
>>
>> Sebastien Lambla writes:
>>>> Is it ever appropriate to configure content negotiation on the
>>>> *representation-specific URIs*? So, if someone requests the
>>>> specific URI
>>>> for representation_1, but the Accept header indicates a preference for
>>>> representation_3, should content negotiation kick in and
>>>> representation_3
>>>> be served instead?
>>>
>>> If your url is the representation-specific one, then the conneg would
>>> fail
>>> if the content-type of /resource.html is text/html and the Accept: only
>>> contains application/xhtml+xml, as the representation is not the
>>> resource
>>> and the url you requested is the one of the representation, not the
>>> resource. I would return a 406.
>>>
>>> I'd understand the reasoning as being that if you dereference
>>> /resource.html
>>> and get a 200 you can assert it is a document, if you were to conneg to
>>> another url from the specific url you loose that assertion as defined in
>>> httpRange-14
>>>
>>> Sebastien Lambla
>>
>> --
>> 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
>>
>>
>