W3C home > Mailing lists > Public > www-tag@w3.org > November 2009

Re: conneg, HTTPbis, and generic resources (status check)

From: Karl Dubost <karl+w3c@la-grange.net>
Date: Wed, 25 Nov 2009 09:49:45 -0500
Message-Id: <AD42178C-8CE2-49AB-A7BF-81A2B9C66277@la-grange.net>
Cc: Dan Connolly <connolly@w3.org>, www-tag@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:31 UTC