- From: Karl Dubost <karl+w3c@la-grange.net>
- Date: Wed, 25 Nov 2009 09:49:45 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Dan Connolly <connolly@w3.org>, www-tag@w3.org
Le 25 nov. 2009 à 03:43, Julian Reschke a écrit : > The only reason why no change hasn't been made yet is that it's not totally clear how the proposed text (which looks good) is to be integrated into the current draft (more precisely, what parts of <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-08.html#rfc.section.4> it's meant to replace). I read in the tag minutes On Sun, 30 Aug 2009 05:20:49 GMT In Draft minutes of TAG teleconference of 13 August 2009 from noah_mendelsohn@us.ibm.com on 2009-08-27 (www-tag@w3.org from August 2009) At http://lists.w3.org/Archives/Public/www-tag/2009Aug/0067.html masinter: That was the original conception when conneg was introduced years ago. In practice, it's now used for lots of other things. ... Sometimes, for example, CSS media queries is used to select best rep. That's not in HTTP. ... We seem to be moving toward "HTTP is used for transporting content; if there's variability desired, the initial bit of content is used to make subsequent decision." Let me share practical experiences with Content Negotiation in a business context (Web agency working for clients). # Content Negotiation on languages Accept-Language http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-08.html#header.accept-language HTTP gives a mechanism for negotiating the language of the ressource upon the Accept-Language parameter. In terms of usability, it seems a good thing, because it helps sharing one URI across different cultures. In terms of SEO (Search Engine Optimization), it is considered a bad practice. The terms in URIs spelling and the content of the page are indexed and are important for a better ranking (view of the market). Search engine indexing bots seem not able to index all individual representations of a resource, so instead of relying on http://example.com/my-unique-link (fr, en) Web agencies will choose to do: http://example.com/fr/mon-lien-unique (fr) http://example.com/en/my-unique-link (en) I'm not sure that the Vary header would solve anything. I have not tested it against search engines indexing bots. Would someone have details about that? Vary: Accent-Language Without counting the issues of IE http://crisp.tweakblogs.net/blog/311/internet-explorer-and-cacheing-beware-of-the-vary.html As well Mark Nottingham tests http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989 # Accept header of User agents Practical experience again. Two sites, a first site (BigOne) with a very high trafic and a second site (SmallOne) not optimized for the trafic BigOne receives. Web developers of BigOne puts an image tag by mistake <img src="http://smallone.example.com/boo" alt="logo"/> The resource http://smallone.example.com/boo is not an image but an html file served with text/html. BigOne killed SmallOne. The browser is requesting a resource parsed from an img element, we can expect the accept header must be something of the type: Accept: image/* And then block the requests of BigOne with a "406 Not Acceptable". We only have text/html for this resource. We implemented it in a test version of SmallOne. It worked perfectly with Firefox 3.5 which sends this when requesting images: Accept: image/png,image/*;q=0.8,*/*;q=0.5 Unfortunately, Opera sends: Accept: text/html, application/xml;q=0.9, application/xhtml+xml, application/x-obml2d, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 And IE, webkit seem to send: Accept: */* No luck. -- Karl Dubost Montréal, QC, Canada http://www.la-grange.net/karl/
Received on Wednesday, 25 November 2009 14:49:57 UTC