- From: Mark Baker <distobj@acm.org>
- Date: Thu, 26 Nov 2009 15:48:33 -0500
- To: Michael Nelson <mln@cs.odu.edu>
- Cc: Herbert Van de Sompel <hvdsomp@gmail.com>, Linked Data community <public-lod@w3.org>, Robert Sanderson <azaroth42@gmail.com>
On Wed, Nov 25, 2009 at 6:08 PM, Michael Nelson <mln@cs.odu.edu> wrote: >> I disagree. 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. > > While the exact line between them might be hard to draw, I'd argue those > aren't HTTP-level events, but instead are HTML-level events. In other > words, I would call those examples "navigation". In addition, navigation > works well for things that can be expressed in HTML wrappers (e.g., "click > here for the PDF version"), but not really for embed/img tags where you want > to choose between, say, .png & .gif. I don't draw much of a distinction there, at least for the purposes of discussions like this; they are all URLs in an HTTP response message. >> >> Server driven conneg, in comparison, is effectively unused. Ditto for >> transparent negotiation. > > I think that is an unfair characterization. I won't guess as to how often > it is done, but it is done. It is just not perceived by the user. I didn't mean to imply it wasn't done. As Richard (and Larry, in his referenced message) point out, User-Agent conneg is pretty common. I was just trying to point out that it's not used nearly as often as client selection. > Almost every browser sends out various "Accept" request headers, and it is > not uncommon to have "Vary" and "TCN: Choice" response headers (check > responses from w3c.org, for example). When done with the 200 response + > "Content-Location" header, the URI that the browser displays does not > change. I used to use w3.org as an example too, but I've learned since that it's the exception, not the rule, for Web site design. >>> 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; > > we'll have to agree to disagree on that; I think they are different > modalities. Fair enough. I'm just offering you my advice based on my extensive experience in this space. You're free not to believe me, of course 8-) As long as you're also supporting agent driven conneg, I'm happy. >> - 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 >> > > I would suggest these are among the reasons we champion the 302 response + > "Location" header approach (as opposed to "200/Content-Location") -- it > makes the negotation more transparent Ah, I see. Yes, I agree that's a good design choice. >> 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 would counter with that fact that CN features prominently in: > > http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ > http://www.w3.org/TR/cooluris/ > > Given the role CN plays in these recent documents, it would seem CN has some > measure of acceptance in the LOD community. Content negotiation is a valuable tool, so I'm glad there's interest, but IMO, both of those documents misrepresent it by only describing the server-driven form. Mark.
Received on Thursday, 26 November 2009 20:49:14 UTC