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 14:35:32 UTC