- From: T.V Raman <raman@google.com>
- Date: Thu, 7 Aug 2008 07:59:01 -0700
- To: richard@cyganiak.de
- Cc: seb@serialseb.com, raman@google.com, john.kemp@nokia.com, www-tag@w3.org, kidehen@openlinksw.com, tthibodeau@openlinksw.com
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