Re: Question about the On Linking Alternative Representations TAG Finding

Richard,

By content negociation I took it to cover both 2616 negociation and the 
process by which httpRange-14 hints at redirecting to an IR from a resource 
that may or may not be an IR.

Maybe I misunderstood the common practice of 303ing from resources that are 
not documents as being supported by conneg, but maybe my understanding has 
been flawed by listening to too many people's opinion on httpRange-14 (as it 
seems everyone has one these days).

Any enlightment would be greatly appreciated.

Sebastien




--------------------------------------------------
From: "Richard Cyganiak" <richard@cyganiak.de>
Sent: Thursday, August 07, 2008 3:34 PM
To: "Sebastien Lambla" <seb@serialseb.com>
Cc: "T.V Raman" <raman@google.com>; <john.kemp@nokia.com>; <www-tag@w3.org>; 
<kidehen@openlinksw.com>; <tthibodeau@openlinksw.com>
Subject: Re: Question about the On Linking Alternative Representations TAG 
Finding

>
> Sebastien,
>
> Just a side note.
>
> Content negotiation as defined in the HTTP spec does *not* involve 
> redirects.
>
> Content negotiation works by serving the appropriate variant directly  at 
> the request URI, along with an optional Content-Location header  that 
> gives a URI for the specific selected variant.
>
> There is a recent bad meme floating around, about implementing content 
> negotiation by redirecting from one URI to another. This is not a good 
> way of implementing content negotiation. In web applications, response 
> time is key. Therefore, redirects should be avoided if possible.  Actual 
> content negotiation implementations, such as mod_negotiation in  Apache, 
> use the redirect-less approach described in the HTTP spec.
>
> (I think the meme is an unfortunate result of people getting confused  by 
> the 303 redirects in the httpRange-14 debate. Again, content  negotiation 
> does *not* require redirects and should be done without  when possible. 
> The 303 approach uses redirects for a different reason.)
>
> Richard
>
>
>
> On 7 Aug 2008, at 14:39, Sebastien Lambla wrote:
>
>> So to get in context, if a generic resource redirects to a variation 
>> with its own URL that will return a 200, hence an IR, one argues  that 
>> conneg should still be possible from the IR to another IR  related to the 
>> original generic resource?
>>
>> I argue that one should only allow conneg within the new scope  allowed 
>> by the IR, so that Conneg on /genericresource with accept: 
>> application/html+xml will redirect to /genericresource.html, but if 
>> requested as text/plain should fail. /genericresource.html should 
>> however be able to conneg on other variables such as the language  and 
>> may redirect to /genericresource(en).html
>>
>> In that definition there is no real generic resource, there is a  chain 
>> of resources that are more and more specialized, reducing at  each step 
>> the range you can conneg against.
>>
>> Seb
>>
>>
>>
>> --------------------------------------------------
>> From: "T.V Raman" <raman@google.com>
>> Sent: Thursday, August 07, 2008 2:20 PM
>> To: <john.kemp@nokia.com>
>> Cc: <raman@google.com>; <richard@cyganiak.de>; <seb@serialseb.com>; 
>> <www-tag@w3.org
>> >; <kidehen@openlinksw.com>; <tthibodeau@openlinksw.com>
>> Subject: Re: Question about the On Linking Alternative  Representations 
>> TAG Finding
>>
>>> Correct, that is why I carefully separated out user-agents that
>>> send accept=*/* from other types of agents. When a user-agent
>>> sends out an explicit list of mime-types that it will accept for
>>> content negotiation I think the client and server should do full
>>> content negotiation as was originally intended by HTTP's content
>>> negotiation scheme.
>>>
>>> John Kemp (Nokia-S&S/Williamstown) writes:
>>> > ext T.V Raman wrote:
>>> >
>>> > [...]
>>> >
>>> > > Returning to your final question, where the user-agent does
>>> > > content-negotiation, indicates a preference for one type, but
>>> > > asks by URI for the other, I would say respect the URI. I dont
>>> > > claim this to be *correct* in any sense, other than that I would
>>> > > break the tie this way. Reasoning: The client, by asking for a
>>> > > URI that directly resolves to a given representation has
>>> > > essentially bypassed content-negotiation.
>>> >
>>> > I think your interpretation is OK. But other servers may wish to
>>> respect
>>> > the HTTP Accept header sent in the request, rather than (or in
>>> addition
>>> > to) parsing the URI. This is server-driven negotiation, and the
>>> server
>>> > is attempting to meet the needs of its client. If the server feels
>>> > unable to adequately determine what the client wants, it may
>>> return an
>>> > HTTP 303 or 406 status code and allow the client to make a choice 
>>> > itself.
>>> >
>>> > All of that is in the HTTP 1.1 specification. Anything other than
>>> HTTP
>>> > would presumably define a similar mechanism.
>>> >
>>> > I believe it makes sense to recommend that HTTP 1.1 content
>>> negotiation
>>> > via the HTTP Accept: header is the preferred mechanism for
>>> "breaking the
>>> > tie". If the user-agent can set the Accept header value to
>>> something
>>> > more specific than */* then it is already likely capable of
>>> setting the
>>> > _correct_ value for this header to get the content type it is
>>> asking > for.
>>> >
>>> > Regards,
>>> >
>>> > - johnk
>>>
>>> -- 
>>> 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, 7 August 2008 15:05:16 UTC