Closed Bug 651503 Opened 13 years ago Closed 12 years ago

Remove the frozen date from the User Agent String and replace it with the Gecko version

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 588909

People

(Reporter: djcater+bugzilla, Unassigned)

References

()

Details

+++ This bug was initially created as a clone of Bug #649435 +++

This is an alternative to bug 649435 as the proposal there goes against the spec and produces an invalid UA string. See bug 649435 comment 26 for the relevant sections of the spec and possible consequences.

The version would then be duplicated with the rv: section. A separate followup bug to remove the rv: version that would be needed, as there are new compatibility concerns there.

Note: this does *not* remove the buildid from navigator.buildId.  If someone wants that changed, you should file a new bug as this is *not* the place to discuss that.
Depends on: 651504
No longer depends on: 651504
See prior discussion in bug 588909 on pros and cons for such a move.
Depends on: 588909
(In reply to comment #1)
> See prior discussion in bug 588909 on pros and cons for such a move.

Indeed, not sure how I forgot about that.

The rationale for WONTFIX came in bug 588909 comment 22.

"The rationale here was that we're not dropping the 'rv:' token, because it's
been the recommended way of sniffing for Gecko-proper browsers, along with
"Gecko/", and is doubtless used all over the place. Given that, there's no
point in duplicating information. It's purely an aesthetic argument."

So as long as moving or removing the rv: section is not an option, the choice appears to be duplicate information vs. nonsensical build date.
Don't forget that we can also use user agent like this
Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/rv:6.0a1 Firefox/6.0a1

compared to how it's now
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110419 Firefox/6.0a1

It will be compatible with sniffing for Gecko version.
I think this was dismissed due to the ':' not being allowed in the sub-product string part, confirmed in bug 649435 comment #26, so won't work even though I agree that it would elegantly solve the issue. If I recall correctly what I've tested some time ago, the string without "rv:" would break ASP-based sites.
If this wasn't allowed in sub-product part, how about this ?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:6.0a1) Firefox/6.0a1

I think we should redo the tests to get sure how sites behave on different modifications.
This would correspond to Dave's proposal in bug 588909 comment #18 and likely be the most "sniffer-compatible" version (modulo removing the build date).
Bug 649435 comment 37 makes an interesting suggestion. If the bump to 10 is indeed going to cause trouble, like it did for Opera, we could deal with that by freezing rv: at rv:9.0 and introducing Gecko/10 at the same time.
No changes
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0

j.j. version
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0) Gecko/10.0 Firefox/10.0

j.j. frozen version
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:9.0) Gecko/10.0 Firefox/10.0

My/Dave Garrett version
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:10.0) Firefox/10.0

My future version
Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/10 Firefox/10

My dream version
Mozilla Firefox/10 (Windows NT 6.1; Win64; x64) Gecko/10



Don't forget that we should keep User-Agent as SHORT as possible per HTTP/1.1 specification. So integrating "Mozilla" and 'Firefox" is a must, same as dropping build date and compacting Gecko version.
(In reply to comment #8)
> My/Dave Garrett version
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:10.0) Firefox/10.0
> 
> My future version
> Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/10 Firefox/10

These two are in conflict. After shipping Gecko/rv:version, moving to Gecko/version would certainly be painful.
(In reply to comment #8)
> My future version
> Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/10 Firefox/10

That's what I'd vote for, though I wonder if we'll perhaps even need to keep the rv: part even though it's redundant (one could argue that with Gecko and Firefox versions now being the same, there's some redundancy even there).

> My dream version
> Mozilla Firefox/10 (Windows NT 6.1; Win64; x64) Gecko/10

That is strange and at least the wrong order of things. My dream version would be

Gecko/10 (Windows NT 6.1; Win64; x64) Firefox/10

but I think that won't be doable.
(In reply to comment #10)
> (In reply to comment #8)
> > My future version
> > Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/10 Firefox/10
> 
> That's what I'd vote for, though I wonder if we'll perhaps even need to keep
> the rv: part even though it's redundant (one could argue that with Gecko and
> Firefox versions now being the same, there's some redundancy even there).

There was consensus that rv: needs to be kept for the time being. I think there might be a chance to get rid of it in 2+ years if we freeze it at 9.0.
> It will be compatible with sniffing for Gecko version.

It's common to extract the version by sniffing for "rv:(.*)\)" so putting the rv: bit somewhere not followed by a ')' will break sites.
If this (or any other) bug proposing changes to User-Agent isn't proposing that we hack it all the way down to "Firefox/x.y (CPU; OS)" then I don't see that there's much point, and I'd rather not be cc:ed.
So this will be the best choice for now ?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:6.0a1) Firefox/6.0a1

compared to how it's now
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110419 Firefox/6.0a1
(In reply to comment #14)
> So this will be the best choice for now ?
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:6.0a1) Firefox/6.0a1

That's debatable. It would be a dead end, see comment 9.
Also, having "Gecko/rv:10" breaks everyone sniffing for Gecko/<numbers> which I'm pretty sure is around enough. 

What I guess we need to end up with for now is something like:

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0) Gecko/8 Firefox/8

This one should pass for practically all sniffers out there and is sending fewer bytes than today, which is also a requirement we IIRC have.
> (In reply to comment #10) redundant (one could argue that with Gecko and
> Firefox versions now being the same, there's some redundancy even there).

Interesting statement, do you intend to synchronize SeaMonkey version numbers with Gecko as well, in which case the "rv:" indeed would be redundant, unless some other application objects and dares to keep their own version scheme?  :-)

> > Mozilla Firefox/10 (Windows NT 6.1; Win64; x64) Gecko/10

I think the 1st-token space violates the syntax, that was proposed before.

> (In reply to comment #15) It would be a dead end, see comment 9.

The question is where to go on the short run and where to see the "final" string if you could redesign it from scratch. The comment #10 version

> Gecko/10 (Windows NT 6.1; Win64; x64) Firefox/10

was proposed before as well, removing the Mozilla part used by too many other non-Gecko browsers anyway and replacing it with the Gecko token, then leaving the platform/build-specific tokens in the comment with one or more application tokens following at the end. Looks esthetically pleasing but would break things at this time. The transition from Gecko 9.x to Gecko 10.0 might be the right time to make such a fundamental change but I don't think it should be done now.
(In reply to comment #16)
> Also, having "Gecko/rv:10" breaks everyone sniffing for Gecko/<numbers>
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0) Gecko/8 Firefox/8

This would break any (stupid) sniffer which is checking Gecko-date > 20100101, given that 8 < 20100101, so that's not a fool-proof alternative either...  :-\
(In reply to comment #13)
> If this (or any other) bug proposing changes to User-Agent isn't proposing that
> we hack it all the way down to "Firefox/x.y (CPU; OS)" then I don't see that
> there's much point, and I'd rather not be cc:ed.

You were CCd because this bug was filed as a clone. Your proposal loses the rendering engine and is therefore no good.

I'm going to henceforth browse with this change (using general.useragent.override) and see what happens. Does anyone know of any specific sites already that will break?

I'm linking to bug 572661 comment 12 here because it took me a while to find it and it's useful to see the history of this part of the UA. It links to the 3 bugs which changed the format of the date in the UA, from YYYYMMDD to YYYYMMDDhh, to YYYYMMDDhhmmss and back to YYYYMMDD again.
(In reply to comment #17)
> > > Mozilla Firefox/10 (Windows NT 6.1; Win64; x64) Gecko/10
> 
> I think the 1st-token space violates the syntax, that was proposed before.
> 

It doesn't because "Mozilla" would be a separate product (that user-agent has the form: product product/product-version comment product/product-version). It just has the aesthetic property that it reads as "Mozilla Firefox". Removing the Mozilla product completely is probably not possible at the time being, and would put Firefox in the strange position of being the only major browser without it!

I think greenfield and radical UA changes should go in bug 584683 or another bug. This bug proposes one of the ways to get rid of the nonsensical string "20100101".
(In reply to comment #20)
> [...] Removing
> the Mozilla product completely is probably not possible at the time being, and
> would put Firefox in the strange position of being the only major browser
> without it!
> 
> I think greenfield and radical UA changes should go in bug 584683 or another
> bug. This bug proposes one of the ways to get rid of the nonsensical string
> "20100101".

Right, that stuff has nothing to do with this bug. Please stop discussing it here.
(In reply to comment #17)
> Interesting statement, do you intend to synchronize SeaMonkey version numbers
> with Gecko as well

I don't intend to make any decisions for SeaMonkey any more, I'm pulling out of that project and am working for Mozilla/Firefox now, if you haven't noticed. I intentionally have not even mentioned SeaMonkey in any statement in this bug.


(In reply to comment #18)
> (In reply to comment #16)
> > Also, having "Gecko/rv:10" breaks everyone sniffing for Gecko/<numbers>
> > Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:8.0) Gecko/8 Firefox/8
> 
> This would break any (stupid) sniffer which is checking Gecko-date > 20100101,
> given that 8 < 20100101, so that's not a fool-proof alternative either...  :-\

Nothing is fool-proof, of course. But note that the variant I mentioned there and which you quoted here is exactly what the subject of this bug suggests (with the tweak of only using the major number in the Gecko and Firefox tokens, as we should not send anything on a1/a2 in the future and we only bump major versions in the new development scheme anyhow).
(In reply to comment #19)
> I'm going to henceforth browse with this change (using
> general.useragent.override) and see what happens. Does anyone know of any
> specific sites already that will break?

Well that didn't take long :-( Which page is sniffing the date as a date? Only the number 1 most visited page on the web, the Google homepage! I'll file a tech evangelism bug when I've dug deeper, because they shouldn't be relying on that part being a date (or if they really want to then only do it for Gecko < 4).
I filed bug 651674. It seems that Google thinks the browser is simultaneously Firefox > 2 and Netscape < 7...
I propose we paint this bikeshed like this:
 * Let's scope the rv: stuff outside this bug.
 * Let's put the Gecko major version without dot anything after the "Gecko/" bit (i.e. "Gecko/10"), since with the current versioning plan, the dot part shouldn't be of interest to Web sites anyway, is redundant with the dot part of the Firefox version (which can't realistically be removed) and would just waste two bytes per HTTP request.

That is:
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/10 Firefox/10.0

I'll send email about bug 651674 to the right place.
I think that should be discussed separately, in bug 572659 or a new bug once this one has been fixed. It has separate advantages and disadvantages to this bug.

This bug is about duplicating the rv: number into the Gecko product-version. This doesn't block your suggestion from ever happening because if we've managed to get as far as landing this change, then sites have already stopped treating it as a date and going from 10.0 to 10 is unlikely to cause problems. It may even pave the way for getting rid of the rv: section if that became the standard way of determining the Gecko version.

If you wanted to save bytes though, the first release of each version could omit the .0 (and security releases could be called 10.1 rather than the redundant 10.0.1), but that's for the other bug.
Comment #25 doesn't sound like bikeshedding but like just fixing what's in the summary, I think that's indeed the way to go in this bug. And no, I don't think that we need to copy the dot and whatever follows it.

(In reply to comment #26)
> going from 10.0 to 10 is unlikely to cause problems.

Wrong. People who jump onto the new thing might actually do a match for /Gecko\/\d+\.\d+/ once we do this, so better avoid it. Also, with Henri's suggestion, someone who matches against /Gecko\/\d+/ just "magically" happens to still succeed. ;-)
I was thinking that at some point, someone, somewhere is going to want to check for a specific point release server side. With that change, those people would have to check the Firefox version as the Gecko version wouldn't give them that information.
> I was thinking that at some point, someone, somewhere is going to want to check
> for a specific point release server side

1)  We don't plan to do point releases, except as firedrills.
2)  We don't plan to expose the point release number to websites if we do one.
(In reply to comment #29)
> > I was thinking that at some point, someone, somewhere is going to want to check
> > for a specific point release server side
> 
> 1)  We don't plan to do point releases, except as firedrills.
> 2)  We don't plan to expose the point release number to websites if we do one.

3) There is a separate bug open on making detailed information available to those website that need it, but not without the user being asked if he wants to hand data over, unless a site has been whitelisted (bug 648444).
(In reply to comment #29)
> 1)  We don't plan to do point releases, except as firedrills.
> 2)  We don't plan to expose the point release number to websites if we do one.

Which bug is point 2? Presumably it needs code changes so that the version shows up in about:support / the About window but not the UA string (and is therefore Fx 6 onwards).

https://groups.google.com/d/msg/mozilla.dev.planning/AWYuh9LpwG8/Dew7HOP0zH0J says:

"If needed, the chemspill for 5.0 will be 5.0.1 (haven't had time to update the chemspill section yet but we have it pretty nailed down). This makes it so tools and web sites can only look at the 1st 2 digits if they only care about the "family". In general, 5.0.1 should be exactly the same as 5.0 and tools/websites should be able to group accordingly. I don't think we want 5.1 as tools/websites may still see the 2nd number as significant (as it was for 3.5 -> 3.6)."
> Which bug is point 2? 

I don't think there is one right now.
There was bug 572659 on the Gecko patch level which had been won't-fixed.
Depends on: 660498
I propose we should not make any changes to the UA string, and should close all of these related bugs WONTFIX.
Why?
We should finally remove this useless part of User Agent and "fix" this wrong behavior of looking for it.
It's compatible with properly written sniffers (based on GeckoIsGecko) looking after "Gecko" and "Gecko/", so it's not a big problem.
I concur with comment 25, with a caveat:
* Freeze the rv: number at whatever version of Gecko the train that the change lands on is. (7, at this point?)
* Change the Gecko version token to that same major version (without any point releases).

This would result in, e.g.:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/7 Firefox/7.0.1

Since there's not much you're gonna get out of knowing the Gecko version beyond that it's > 2, this would effectively discourage using UA sniffing and further encourage feature sniffing.

It would also have the benefit, still, of not breaking the sniffers that know that Gecko Is Gecko and are search for the 'rv:' part.

It would also not break the sniffers looking for 'Gecko/' (as long as they have no expectations for what comes after it, beyond that it's a digit).

In addition, it doesn't add the '.' which would break /d+/ sniffers. The only downside (which the date freeze was supposed to discourage) is for those sniffers that are still looking for an 8-digit date.

Then, somewhere down the road, the removal of the redundant 'rv:' part could be discussed.
No longer depends on: 588909
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
No longer depends on: 660498
You need to log in before you can comment on or make changes to this bug.