ryah dahl wrote: >>> 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". >>> >> Of course we can spend time on edge cases like these. >> >> But if we do, I'd prefer to talk about repeating Content-Length or >> Content-Type headers first, because those may have security implications. >> > > Isn't the only use for q-value to give equal preference to several > values? As far as I see it, the whole q-value topic is an edge case. I > think it should be depreciated in favor of ordered lists. > > ordered lists don't allow you to specify holes in a range of acceptable values, e.g. Accept-Language: en, en-us;q=0 which means any english except US. I don't see any problem with the current spec. If UAs really don't want to specify a real preference (i.e. assign same q value, either explicitly or implicitly to multiple options), then as long as that is really a representation of the human user's wishes, what's the problem? If we start to consider having a qvalue on "*" to be a problem, we might be tempted to take steps which will arbitrarily limit us (and cause actual problems) later. But logically, being able to specify a qvalue for anything is just part of being able to define logical statements. Regards Adrien > In the case where this might be meaningful, Accept-Language, UA do not > give the ability of the user to specify something more detailed than > an ordered list of perfered languages. Accept, Accept-Charset - who > cares? Is an ordered list ever not enough? > > ry > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.comReceived on Monday, 4 August 2008 21:13:06 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC