Closed Bug 581783 Opened 14 years ago Closed 14 years ago

Remove "Windows;" from the UA string

Categories

(Core :: Networking: HTTP, defect)

All
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b4

People

(Reporter: dao, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [parity-IE][parity-opera])

Attachments

(1 file)

The "Windows;" token is useless, as it's always followed by "Windows Foo..." (where "Foo" usually is "NT"). UA string parsers are unlikely to look for "Windows;" including the semi-colon, because:

IE apparently dropped "Windows;" with IE8:
http://www.useragentstring.com/pages/Internet%20Explorer/

Opera never had it, except when it claims to be gecko or webkit:
http://www.useragentstring.com/pages/Opera/
And with Linux it always has "X11;" and with Mac OS X it always has "Macintosh;". The leading platform token is redundant for pretty much everyone and is more obviously redundant with the removal with the intervening "U;". It's probably best to remove this token for everyone. If there is a platform that actually does need it, then for that one it can be merged into the OS/CPU part.

All current possibilities for this platform token:
/netwerk/protocol/http/nsHttpHandler.cpp
687     mPlatform.AssignLiteral(
688 #if defined(ANDROID)
689     "Android"
690 #elif defined(XP_OS2)
691     "OS/2"
692 #elif defined(XP_WIN)
693     "Windows"
694 #elif defined(XP_MACOSX)
695     "Macintosh"
696 #elif defined(XP_BEOS)
697     "BeOS"
698 #elif defined(MOZ_X11)
699     "X11"
700 #else
701     "?"
702 #endif
703     );
The difference is that sniffers looking for X11 or Macintosh won't find it in the OS_CPU token. So that stuff deserves a separate bug.
Attached patch patchSplinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #460143 - Flags: review?(bzbarsky)
(In reply to comment #2)
> The difference is that sniffers looking for X11 or Macintosh won't find it in
> the OS_CPU token. So that stuff deserves a separate bug.

Also note that Opera used to include Macintosh and X11 despite the omission of Windows. However, they seem to have dropped X11 recently. Not sure about Macintosh.
Hiding this just for Windows would lead to an inconsistent UA across platforms with a different number of tokens on different OSes, possibly leading to inconsistent parsing. Just removing the "Windows;" itself may break some UA parsing if OS checking is simply done by the first token, so it makes sense to break it for everyone at once and remove all the redundant data for everyone.
Sniffers cannot make sane assumptions about the number of tokens. It isn't fixed for Gecko (e.g. because of the 64bit stuff), we've already reduced the average token count from previous releases, and it greatly varies across browsers. With that in mind, see comment 2 and comment 4.
The "X11" token is used for UNIX platforms as well, thus a general indicator
for the window system used. Strictly speaking, you could also run an X11 server on a Windows platform, though I don't think anybody would run a modified Gecko application on top of it.
(In reply to comment #4)

> Also note that Opera used to include Macintosh and X11 despite the omission of
> Windows. However, they seem to have dropped X11 recently. Not sure about
> Macintosh.

Opera 10.6 Mac:
Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.6.30 Version/10.60

(I am all in favour of dropping 'Macintosh' - it is useless, along with 'PPC/Intel' and the OS X version)
(In reply to comment #8)
> (I am all in favour of dropping 'Macintosh' - it is useless, along with
> 'PPC/Intel' and the OS X version)

See also the really awesome bug 414057 :P
Comment on attachment 460143 [details] [diff] [review]
patch

r=bzbarsky
Attachment #460143 - Flags: review?(bzbarsky) → review+
Chris, let the Google folks know?
(In reply to comment #11)
> Chris, let the Google folks know?

Because of bug 579161, I suppose?
Yes.  Apparently their ua parsing is ... fragile.  They asked us to let them know when we make UA changes.
Attachment #460143 - Flags: approval2.0?
Blocks: 582685
No longer blocks: 582685
(In reply to comment #9)
> (In reply to comment #8)
> > (I am all in favour of dropping 'Macintosh' - it is useless, along with
> > 'PPC/Intel' and the OS X version)
> 
> See also the really awesome bug 414057 :P

I can't believe I am asking this: If we don't like the OSX version, why do we keep the Windows version in there?
Because that would be controversial whereas removing the redundant "Windows;" token is not. I think bug 57555 covers the Windows version.
I'll let them know once we're done making changes.  Until then it's just churn.
Has everyone decided how much UA fiddling are we going to do? I'd like to land and message it all at once, rather than piecemeal.
I don't think more changes are going to happen soon. I don't see other low hanging fruits. Bug 414057, bug 527886, bug 572659, bug 572661 and bug 572665 all seem controversial and don't have owners. I'd like to get bug 581008 done, but that wouldn't affect the default string.
Comment on attachment 460143 [details] [diff] [review]
patch

a=beltzner for when the tree re-opens, we may have to back this out if it causes a ton of problems
Attachment #460143 - Flags: approval2.0? → approval2.0+
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/35b64ad7910c
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
Blocks: 589353
(In reply to comment #7)
> The "X11" token
... and lots of other "token" talk.

These are tokens only in our own minds. The UA spec has product tokens and paren-delimited free-form "comments". We (and other vendors) can sprinkle ';' all we like in the comment for readability, but there's nothing special about having fewer or more of these non-token "tokens". A shorter UA is appreciated, however.
The other platform-specific "comment items" [ better? ;-) ] are now handled in bug 589353 with a suggestion to make the order and content more consistent.
Depends on: 637395
You need to log in before you can comment on or make changes to this bug.