Re: Question about the On Linking Alternative Representations TAG Finding

Absolute -- well said re redirects and their abuse! As the world
tries to go Carbon Neutral, we should start a parallel campaign
to make the Web 302 free (where possible)

Richard Cyganiak writes:
 > 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
 > >>

-- 
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:00:02 UTC