- From: <bugzilla@jessica.w3.org>
- Date: Tue, 03 Jan 2012 16:13:38 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15380
--- Comment #8 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-01-03 16:13:36 UTC ---
(In reply to comment #7)
> > > The reason I ask is that if the string still contains something UA-specific, is
> > > there any reason to think that the de-facto requirements for what to include in
> > > will now keep expanding with the ebb and flow of browser market share?
[... snip ...]
> Actually, I was interested to hear everyone's opinions on this. Specifying part
> of the UA string is obviously better than specifying none of it, but is it too
> far-fetched to suggest that all of it be specified? There are downsides of
> course, but imagine to remove this source of incompatibilities forever!
What did you mean by "still contains something UA-specific" above? I think it
could be quite ideal if there were rules for "all of it", that would not be far
fetched, at all. However, previoiusly I read you to suggest that all UA strings
should be one and the same - identical. I probably misread you then, sorry.
[... snip ...]
> I wasn't at all involved, but my guess is that everyone knows that changing the
> UA string *at all* is guaranteed to cause compat issues somewhere, so it's not
> exactly a safe way to fix compat issues elsewhere.
That sounds true. Nevertheless: Trident, Gecko and Webkit all updated their UA
strings this year. Are there important incompatibilities from that? Also, each
time the browser is released on a new hardware platform - or a new version of
the browser is released, the string updates too ... (Opera has, because of
this, stopped updating the first token of its string - which now just remains
Opera/9.80 ... guess it can't do that forever? Opera back then, at version 10,
asked what the other vendors would do - and perhaps they solved it by always
starting with the token Mozilla/\d ???)
A most interesting detail in regard to what Gecko and Webkit did is that they
standardized on strings of the following format:
"[mainproduct string]" (e.g. Firefox)
"[mainproduct string]+[sideprodstring]" (e.g. SeaMonkey)
Example:
Firefox:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
SeaMonkey:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
SeaMonkey/2.1.1
This shows that
a) a realization of the need streamline the strings.
b) streamlined strings can without much risk be made longer
> > Now, let us assume that Opera *had* changed the UA string to something that
> > worked: Would you have done do so silently? Or would you have told the world?
> > If the UA string format was kept track of somewhere, then you could have
> > reported your change and your incompatibility findings to that UA string
> > tracker, and thereby benefited "the Web"?
> >
> > There is every reason to think that such a UA string registry would not put an
> > end to the "development" of new UA strings. But then, that has never quite been
> > the purpose of such registries either. (Also, it could be that XML5 will allow
> > fatal errors to be handled differently.) But the registry would let us -
> > vendors and site/server developers - to have this important detail under
> > systematic scrutiny. E.g. perhaps Opera would have discovered this problem much
> > earlier. ANd perhaps ASP would have been fixed also ...
>
> I agree 100%, the more of the UA string that is specified the better for the
> Web in general and small players in particular.
Great to hear!
> > Btw: As is, if a web developer want to discern between GUI browsers and other
> > user agents, then the token 'Mozilla/\d' is the the safest, single-token. The
> > *important* *exception* is Opera.
>
> Huh, I did not know that,
Mosaic killers, that was what they all wanted to back then ... As for "know":
I just counted the strings at http://www.useragentstring.com/pages/All/. 81% of
them begin with the token "Mozilla/\d.\d". (But only 1000 - 10% - contains
"Mozilla/\d.\." *and* a product token (or a *comment*) which says "MSIE \d.\d"
OR "Firefox/\d" OR "Safari/\d". Note that Microsoft always places the "MSIE
\d.\d" inside a comment - it is not a product token.
> but I'm guessing that there's some historical reason
> for why Mozilla/0 is not part of our UA. It seems likely that adding it now
> would cause all kinds of things to break, but perhaps it would fix some as
> well..
You could add it at the *end* of your curren string - see the SeaMonkey example
above.
This is the string I "made" in my www-tag@ message,
where I added it inside a comment (the parenthesis):
Opera/11 Version/11.60 Presto/2.2.15 (boilerplate:Mozilla/5.0/msie 10.0)
This is a current, "real" string (from
http://www.useragentstring.com/pages/Opera/):
Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; de) Presto/2.9.168
Version/11.52'
As I said above, Opera would probably need to fix
the "9.80" part at some point. So a new string could
look like this, where I replaced 'boilerplate' with
'compat'):
Opera/11 (Macintosh; Intel Mac OS X 10.6.8; U; de) Presto/2.9.168 (compat:
Mozilla/5.0; msie 10.0;) Version/11.52
Compared to the current, real string, the changes are
quite minimal, and it makes it work with the ASP
affected pages, like this this one:
http://home.mcafee.com/Default.aspx
Note, as well, that the above string follows the advice
in HTTP 1.1 about having the most specific product token
first and then becomes more and more unspecific.
The more "traditional" option would be to start with the
Mozilla/0 product token, where I guess you would
coordinate the number with your competitors:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6.8; U; de) Presto/2.9.168 Opera/11
Version/11.52 (compatible: msie 10.00)
This too works with that ASP page.
Note that this option starts with the more general info
and ends with the most specific info. (Opera's
Version/\d does perhaps not fit in, though.)
Perhaps it makes sense, from a compatible-with-the-Web point of view, to start
with the least specific and end with the most specific. That approach seem more
compatible with the thought of a - ideally - versionless Web than the opposite
- to let the string start with a product token with a speedily increasing
number.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 3 January 2012 16:15:42 UTC