W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

RE: qvalue *

From: Robert Brewer <fumanchu@aminus.org>
Date: Mon, 4 Aug 2008 12:24:31 -0700
Message-ID: <F1962646D3B64642B7C9A06068EE1E64043962E9@ex10.hostedexchange.local>
To: "Frank Ellermann" <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, <ietf-http-wg@w3.org>

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
> > I'm still not sure how this is a problem, unless you can
> > show that this causes interop problems somewhere.
> 
> The <qvalue>s are supposed to mean something.  In the case
> of Accept-Language: en,de,frr;q=0.1,frs;q=0.1  I'd guess
> (and implement) that this means "user wants 'en' or 'de',
> if both are unavailable frr or frs".  If 'en' *and* 'de'
> are available toss a coin, or take always the first / last,
> the user doesn't care.  Ditto if frr *and* frs exist, but
> no 'en' and no 'de'.
> 
> So far it is simple, and no reason to talk about it in the
> spec.  Now back to our Accept-Charset cases cases, assume
> that Koi8-R, BOCU-1, and UTF-8 are available:
> 
> All match *;q=0.7.  Toss a coin ?  Take always the last,
> i.e. for utf-8;q=0.7,*;q=0.7 take the * and toss a coin ?
> 
> This is _relatively_ harmless (unless you get BOCU-1 and
> your UA can't handle it, obviously).
> 
> But it is strange when the <qvalue> of * isn't one of the
> smallest non-zero <qvalue>s, and I'm surprised that folks
> here refuse to see it.
> 
> But why ?  If everybody does something else the wildcard
> can be simply deprecated.  Or if desired fixed in some
> way, e.g., state that a wildcard <qvalue> greater or
> equal than the smallest non-zero <qvalue> elsewhere MUST
> be interpreted as *;q=0.001.  Or SHOULD.  Or something
> better than "dunno, who cares, toss a coin, get BOCU-1".

I don't think "toss a coin" is the only answer. For example, CherryPy
allows web app authors to provide a default encoding per resource [1],
which will be used if '*' is the first acceptable match in an
'Accept-Encoding' request header. Another option is to allow the app
author to provide an ordered list of desired values; CP uses this
technique for the 'Accept' header [2]. This is also specifiable per
resource.

Hmm...maybe we should unify those. ;)


Robert Brewer
fumanchu@aminus.org

[1] http://www.cherrypy.org/browser/trunk/cherrypy/lib/encoding.py#L151
[2] http://www.cherrypy.org/browser/trunk/cherrypy/lib/cptools.py#L366
Received on Monday, 4 August 2008 19:24:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT