Closed Bug 660498 Opened 13 years ago Closed 12 years ago

Remove the frozen date from the User Agent String and also move Gecko/ to precede rv:

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: djcater+bugzilla, Unassigned)

References

(
URL
)

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.

This proposal would lead to a UA string like:

Mozilla/5.0 (X11; Linux i686; Gecko/rv:7.0a1) Firefox/7.0a1

The reasons for this proposal are:

- It gets rid of the nonsensical date "20100101"
- It is compatible with http://archive.bclary.com/lib/js/geckoGetRv.js
- It is compatible with pages which sniff for "Gecko/" in the UA string

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.
> - It gets rid of the nonsensical date "20100101"

So far I'm aware of Firefox only as being the single application which froze the build date, neither Thunderbird nor SeaMonkey followed that example (and yes, I think I'm repeating myself having pointed that out elsewhere already).

I'm wondering if it's really useful to have half a dozen bugs on variants of what's essentially the same issue and thus distributing that discussion over multiple places rather than having a concentrated review of what's best...
(In reply to comment #1)
> I'm wondering if it's really useful to have half a dozen bugs on variants of
> what's essentially the same issue and thus distributing that discussion over
> multiple places rather than having a concentrated review of what's best...

Yeah, this is slightly annoying.

I'm opposed to what this bug is suggesting, since I think there are better alternatives. I think we should aim for less quirkiness and take the opportunity to deprecate the rv token by freezing it when we move from 9 to 10, which could otherwise break sniffers like it did for Opera. In short, this is what I'd like to see:

Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/10 Firefox/10
(In reply to comment #2)
> Yeah, this is slightly annoying.
> 
> I'm opposed to what this bug is suggesting, since I think there are better
> alternatives. I think we should aim for less quirkiness and take the
> opportunity to deprecate the rv token by freezing it when we move from 9 to
> 10, which could otherwise break sniffers like it did for Opera. In short,
> this is what I'd like to see:
> 
> Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/10 Firefox/10

http://archive.bclary.com/lib/js/geckoGetRv.js is unaffected by the move from 9 to 10 and will return 9 for the UA above.

Bug 651503 covers replacing the date with the Gecko version but is blocked on at least bug 651674.
(In reply to comment #3)
> http://archive.bclary.com/lib/js/geckoGetRv.js is unaffected by the move
> from 9 to 10

I wouldn't have expected otherwise from a script coming from the mozilla community. This isn't necessarily representative.

> and will return 9 for the UA above.

Obviously.
It's time to decide whether we freeze "rv:" version or not.
(In reply to Dão Gottwald [:dao] from comment #2)
> Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/10 Firefox/10

Do we have data indicating that the rv: number is the problem with broken sniffers instead of the Firefox number? The general problem seems to be that the Firefox number is the problem if sites only sniff for the first digit. The first digit after rv: was 1 even for Firefox 3.6.x and so far, which suggests that all the sniffers that have been confused by seeing 1 as the only digit they sniff have been sniffing the Firefox number instead of the rv: number.

Given the available data, I think we shouldn't freeze the rv: number.
Don't forget how to properly spoof Gecko version - http://geckoisgecko.org/
We shouldn't care about bad or broken spoofing...

So proposal in first post looks good, get rid of all this junk data overload...



Is
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1

Will be
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:10.0a1) Firefox/10.0a1
(In reply to Henri Sivonen (:hsivonen) from comment #6)
> The first digit after rv: was 1 even for Firefox 3.6.x and so far, which
> suggests that all the sniffers that have been confused by seeing 1 as the
> only digit they sniff have been sniffing the Firefox number instead of the
> rv: number.

I've read this sentence a couple of times, I don't understand it. :/

(In reply to Virtual_ManPL from comment #7)
> Don't forget how to properly spoof Gecko version - http://geckoisgecko.org/

> Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:10.0a1) Firefox/10.0a1

This is quite ironic. (You're moving the Gecko token into a comment.)
(In reply to Dão Gottwald [:dao] from comment #8)
> (In reply to Henri Sivonen (:hsivonen) from comment #6)
> > The first digit after rv: was 1 even for Firefox 3.6.x and so far, which
> > suggests that all the sniffers that have been confused by seeing 1 as the
> > only digit they sniff have been sniffing the Firefox number instead of the
> > rv: number.
> 
> I've read this sentence a couple of times, I don't understand it. :/

The problem we are seeing is that sites are looking for "Firefox/1" to sniff for unsupported Firefox 1.x and mistake Firefox/10.0 for Firefox 1.x.

We don't have this problem with the rv: token, because looking for "rv:1" would have matched as recently as in Firefox 3.6.

Therefore, freezing the rv: token doesn't help at all with the problems we are seeing when the version number becomes a double-digit number.

So far, it seems to me that the breakage from double-digit *Firefox* version has been so tame that it's not worthwhile to freeze Firefox version number, either.

I think we should continue to keep the rv: number and the Firefox/ number in sync and I think we should continue use them for communicating the real version number.

Anyway, all this is off-topic for this bug report.
Bug 588909 removed the frozen date
Depends on: 588909
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Bug 588909 haven't moved "Gecko/" inside the comment.
Feel free to mark WONTFIX if we will never move.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
No longer blocks: 651503, 651504
Bug #588909 was fixed, so shouldn't we take this opportunity to complete transforming the User Agent String into final version ?
It's a great chance before we will end evangelism of these 'broken' sites.



was:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/20120219 Firefox/13.0a1

is:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/13.0a1 Firefox/13.0a1

will be:
Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/rv:13.0a1 Firefox/13.0a1
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:13.0a1) Firefox/13.0a1



We should also think over dropping the Gecko patch level, as we don't use it anymore with rapid release development cycle
Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/rv:13 Firefox/13.0a1
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:13) Firefox/13.0a1

or even in Firefox we could also try that
Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/rv:13 Firefox/13
Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:13) Firefox/13

We can also consider new spoofing method for Gecko/ and rv: creating a new one, upgrading 'GeckoIsGecko'.
(In reply to Virtual_ManPL from comment #13)
> We should also think over dropping the Gecko patch level, as we don't use it
> anymore with rapid release development cycle

This would be bug 572659 which got WONTFIXED.
(In reply to Virtual_ManPL from comment #13)
> Bug #588909 was fixed, so shouldn't we take this opportunity to complete
> transforming the User Agent String into final version ?
> It's a great chance before we will end evangelism of these 'broken' sites.
> will be:
> Mozilla/5.0 (Windows NT 6.1; Win64; x64) Gecko/rv:13.0a1 Firefox/13.0a1
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; Gecko/rv:13.0a1) Firefox/13.0a1

I was under the impression (or, at least, am of the opinion) that this is not the target UA string, despite GeckoIsGecko. Discussion in bug 588909 seemed to indicate that the goal was to freeze the 'rv:' number within the comment and eventually phase it out in favor of 'Gecko/x.y.z'.

So, yeah, GeckoIsGecko would have to be updated—but not in the way that you think.
I should also note that having ':' in the 'product' token is actually forbidden by the spec:

14.43 User-Agent
       User-Agent     = "User-Agent" ":" 1*( product | comment )

3.8 Product Tokens
       product         = token ["/" product-version]
       product-version = token

2.2 Basic Rules
       token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT
(In reply to Virtual_ManPL from comment #13)
> Bug #588909 was fixed, so shouldn't we take this opportunity to complete
> transforming the User Agent String into final version ?

If you'd followed the discussion there you would notice that they are currently discussing backing this out again, or at least not to allow it to progress onto aurora to give web developers to adapt. Two major issues have already been identified that are regressions from the change in the Gecko token alone.

Also, in agreement with comment #15, moving the Gecko token into the comment (which would be necessary to satisfy the restrictions mentioned in comment #16 on the syntax of regular product tokens) wasn't remotely a future target there despite your repeated attempts to inject it into that discussion.
(In reply to rsx11m from comment #17)
There weren't any discussion at this moment as I posted this.
Also I don't think I'm repeating myself. I only wanted to remind that now it's a good chance to finalized the User Agent String, instead of taking small steps, when we already broke Zimbra and Google

(In reply to [Baboo] from comment #14)
> This would be bug 572659 which got WONTFIXED.
It's magically now reopened ;)

(In reply to Gordon P. Hemsley [:gphemsley] from comment #16)
Thank you for detailed info, I completely forget about HTTP specification
(In reply to Virtual_ManPL from comment #18)
> There weren't any discussion at this moment as I posted this.

Ok, point taken. Since apparently also small changes break some web sites, there is no warranty that putting the Gecko string inside the comment won't break existing sniffing algorithms anyway which don't expect it there. In this sense, it seems more prudent to follow a trajectory which brings the UA string closer to the spirit of the standard rather than trying to squeeze it in a way that old parsing schemes are still supported.

> (In reply to [Baboo] from comment #14)
> > This would be bug 572659 which got WONTFIXED.
> It's magically now reopened ;)

Yes, because of bug 728610, apparently removing the "a1" resolves the issues found there (and they couldn't find a better reason to reopen it, and there is some confusion right now whether or not the "a1" actually breaks it... :-) ).
I think we've established that we're never going to have "Gecko/rv:" anywhere in the string, so I think it's safe to WONTFIX this. Further changes can proceed in other bugs.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.