- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 26 Nov 2009 00:04:49 +0000
- To: Mark Baker <distobj@acm.org>
- Cc: Michael Nelson <mln@cs.odu.edu>, Herbert Van de Sompel <hvdsomp@gmail.com>, Linked Data community <public-lod@w3.org>, Robert Sanderson <azaroth42@gmail.com>
Mark, On 25 Nov 2009, at 21:46, Mark Baker wrote: > I would say that agent-driven negotiation is by far the > most common form of conneg in use today. Only it's not done through > standardized means such as the Alternates header, but instead via > language and format specific links embedded in HTML, e.g. "Click here > for the PDF version", or a "Language/country-selector dropdown" in the > page header, or even via Javascript based selection. > > Server driven conneg, in comparison, is effectively unused. If you choose such a rather broad definition for agent-driven negotiation, then you surely must count the practice of sending different responses based on client IP or User-Agent header, both of which are common on the Web, as examples for server-driven conneg. So server-driven conneg is actually quite common. Best, Richard > Ditto for > transparent negotiation. > >> So while I think you are describing agent-driven CN (or something >> very >> similar), I also think it would be desirable to go ahead and get >> the full >> monty and define the appropriate Accept header and allow server- >> driven & >> transparent CN. Agent-driven CN is still available for clients >> that wish to >> do so. > > I just don't understand the desire for server driven conneg when agent > driven is the clear winner and has so many advantages; > > - not needing to use the inconsistently-implemented Vary header, so > there's no risk of cache pollution. see > http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989 > - more visible to search engines > - simpler for developers, as it's just links returned by the server > like the rest of their app. no need for new server side modules either > > You might also be interested to read this, where one of the RFC 2616 > editors apologizes for supporting server driven conneg; > > http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html > > Note that he refers to HTTP conneg being broken, but is actually only > talking about server driven conneg. > > I think that makes for a pretty strong case against it, and I haven't > even elaborated on the architectural problems I perceive with it > (though some of the advantages above relate closely). > > Mark. >
Received on Thursday, 26 November 2009 00:05:24 UTC