Closed Bug 230182 Opened 16 years ago Closed 11 years ago
"User-Agent" header, in sent messages, should contain more information
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.5) Gecko/20031007 Firebird/0.7 This bug is related to bug 227863. In 227863, "it was decided" to drop some useful information from the User Agent string used when sending Mail/News. Please re-add the following now missing data: - OS - Language These data are useful for example for statistic tools to get information about what a certain user is/might be using. Reproducible: Always Steps to Reproduce:
This main significance of a user-agent header like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 lies in the version and OS information for debugging purposes. It's quite important to get this information when "supporting" via email or newsgroups, since certain problems may be platform-dependend - and end users tend to *not* provide this info in their first messages...
Status: UNCONFIRMED → NEW
Ever confirmed: true
It would be good to have the OS and language information back. Not necessarily for statistical purposes (that would be a side effect), but as Karsten said, it is nice to have for support reasons. And something like "Mozilla Thunderbird 0.5a (20040105/Win98/en-US)" would still be much shorter than "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040105 Thunderbird/0.5a" (47 characters vs 78 characters).
Mozilla Thunderbird 0.5a (Windows NT 5.1;en-US) Gecko/20040109 I feel "Gecko/YYYMMDD" very important here - it's a word anyone can choose to recognize Gecko Engine based product
I thought there was a check-in for additional OS info? Within an actual nightly build I can't see it "Mozilla Thunderbird 0.5a (20040111)".
Henrik, this information can't be found under Help -> About Mozilla Thunderbird. Post a message to a test newsgroup and look at the message source.
Right, my failure... So what if we need further information about the client to give the right support? I would prefer to see the whole (old) UA-String inside "Help | About" like TB always sends by HTTP-Requests. In that combination we see an overview of the affected system and could give best matched answers.
I completely agree with Henrik. What's so bad at all about "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.6b) Gecko/20031205 Thunderbird/0.4" that it needed to be changed? I agree that it's not nicely formatted, but that's all. What about something like (based on my UA pasted above): Mozilla Thunderbird 0.4 (Windows NT 5.1; de-DE; 20031205) (This is basically the same Simon posted in comment #2). I disagree with comment #3. In *Mail* User Agents or X-Mailer headers, Mozilla is only used by Mozilla mail clients (ie. Mozilla-The-Suite and Thunderbird). Thus, the string "Mozilla" is good enough to distinguish a Mozilla based MUA/NUA.
Section 6.18 of http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-12.txt suggest that the User-Agent header should be: header =/ User-Agent-header User-Agent-header = "User-Agent" ":" SP User-Agent-content *( ";" extension-parameter ) User-Agent-content = product *( CFWS product ) product = [CFWS] token [CFWS] [ "/" product-version ] product-version = [CFWS] token [CFWS] It also gives examples: User-Agent: tin/1.3-950621beta-PL0 (Unix) User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486)) User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712) User-Agent: Microsoft-Internet-News/4.70.1161 User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest") User-Agent: inn/1.7.2 A current Tb has: User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040321) That's clearly wrong wrt. usefor. In Usefor, it should be: Mozilla Thunderbird/0.5+ (Windows; 20040321) Also IMO the "20040321" could be seen as a "version" qualifier and should be behind the "0.5+". Yes, I DO know that Usefor isn't authorative and just a draft. Nonetheless, there are some parts from verious drafts of usefor which are followed, and so should this part.
Scott, could you give any comments please? The shortened version string raises confusions for supporters. New users whose want to get help of our newsgroup paste this string: Mozilla Thunderbird 0.6+ (20040417). You can't see the OS und selected language. Every time we have to reask for system information before we could give the correct answers. That's a hassle. Please add these both entries and also take a look at comment 8 which describes the suggestion how the UA should be build.
Since the checkin of bug 227863, the community support of Thunderbird, especially in case of localized versions, is badly hampered. Before this fix, a mail or newsgroup posting contained this fully qualified HTTP style user-agent: > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) > Gecko/20031205 Thunderbird/0.4 The current format > User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040418) still does not provide sufficient data, because you can't tell neither the exact OS nor language. The original first "fix" in bug 227863 was justified with | We should really use a more user friendly user agent But who *are* the users this header needs be more friendly for? As long as everything runs well, Joe User (mostly) won't care about that header. *If* problems occur, Joe User might post to a Mozilla community newsgroup or send some mail to a friendly Mozilla wizard, but usually won't include any (sufficent) data. The old User-Agent header did that for him, and no further to and fro was needed to get this information. The relevant information here are: - OS (as in "Windows NT 5.0", not just "Windows"; this may matter wrt to graphic card drivers etc.) - Language - Thunderbird Version We had a *very* long thread lately in de.comm.software.mozilla.*, the German language Mozilla community newsgroup hierarchy, until it was realized that the user was using a *localized* version of Thunderbird! The second group of people making use of this header are the testers, especially those of nightly builds. When discussing the latest bugs and features (e.g. in de.comm.software.mozilla.nightly-builds), it's just a necessity to know the above mentioned data and of course the: - build date (which should be assumed to reflect vicinity to the source). Summary: This current new form of the User-Agent header is now more readable for those who don't care about it anyway, but next to useless for those who depend upon it. My patch will alter the User-Agent like this: Mozilla Thunderbird 0.6+ (Windows NT 5.0; en-US; 20040418) (The file nsMsgCompUtils.cpp contains *lots* of inconsistent whitespace I corrected also, please see the -w diff for the real minor changes in building the User-Agent string!)
Assignee: mscott → mnyromyr
Status: NEW → ASSIGNED
Comment on attachment 146840 [details] [diff] [review] simple information extension (lots of whitespace, please see -w diff) (please see -w diff for relevant changes when reviewing)
I forgot the "/" required by Usefor and I have been advised kindly not to touch the (whole) whitespace mess. ;-)
Comment on attachment 146844 [details] [diff] [review] simple information extension; Usefor style Please see comment #10 for a rationalization of this patch; the User-Agent format is now Usefor compliant: Mozilla Thunderbird/0.6+ (Windows NT 5.0; en-US; 20040418)
Attachment #146844 - Flags: review?(mscott) → review?(bienvenu)
Comment on attachment 146844 [details] [diff] [review] simple information extension; Usefor style Scott should review the proposed user agent change
Scott, do you think the patch could be applied?
suggestion for the first UA part: "Mozilla-Thunderbird/0.6" (I don't know about the "+") 1. use a line between Mozilla and Thunderbird source: http://asg.web.cmu.edu/rfc/rfc2616.html#sec-14.43 (eg. "CERN-LineMode") 2. use a slash before the product version source: http://asg.web.cmu.edu/rfc/rfc2616.html#sec-3.8 product = token ["/" product-version] also used in FireFox Long term it would be great to have a consistent user agent for all the Mozilla products. Possible duplicate: http://bugzilla.mozilla.org/show_bug.cgi?id=242361
Since the User-Agent string relies upon the data in mozilla/mail/base/locale/brand.properties (to be precise, it should rely upon brandFullName, not brandShortName as it is currently in code and my patch - see bug 240741), we have a problem here: the dash should of course *not* be part of the brandFullName...
s/ /-/g ?
> s/ /-/g ? Yeah, of course - but that's not "pretty". Maybe my view point is far too mathematic to propose something like that. ;-) But now that it's mentioned, I can use it without hiding... :) I'll update my patch as soon as I have a current TB tree again.
heh, funny that you call it "mathematic", but I usually wouldn't propose something like this. But in this case, it seems merely that spaces are not allowed (because spaces are token delimiters) and "-" seems to be the normal replacement. It's not a good solution, and I don't see one that could be inferred from the brandFullName. What, if brandFullName is "AOL (Optimized Version)" or whatever? Apart from the forbidden brackets, you may want to send another string as product identifer than what you show to the user, so the only "right" solution I see is to use a new entity in brand.properties.
hm, brand.properties is localizable. What about a case like in Seamonkey or if AOL decides to ship it and call it "AOL Mail", and then localizes the "Mail"? The UA string should be fixed for a product, no matter the locale, so you can't use mozilla/mail/base/locale/brand.properties anyways.
> What about a case like in Seamonkey or if AOL decides to ship it and call it > "AOL Mail", and then localizes the "Mail"? If we introduce a new property like "brandUserAgentName", it should clearly be marked as non-*local*izable (and get a comment about how to construct it). We should, however, have this string in exactly *one* location so that every part of Mozilla/TB/whatever that needs it can get it easily. So I think that brand.properties is still the place to put it in.
*** Bug 311519 has been marked as a duplicate of this bug. ***
Comment on attachment 146844 [details] [diff] [review] simple information extension; Usefor style We've shipped with the current UA since December of 2003 and I'm still happy with it and am not keen on changing it. I recognize that not everyone is happy with that :)
Yes, it is broken since 2003-12. But what was the actual reason for this change? Where's the gain in that unneccessary shart UA? And why don't you want to revert your error?
(In reply to comment #26) > We've shipped with the current UA since December of 2003 and I'm still happy > with it and am not keen on changing it. I recognize that not everyone is happy > with that :) Why not? It's cool short! I like the bug reports of people whose don't know much about Thunderbird and their system. So you have to ask twice or more to get the full information you need to start any qa work. That's not frustrating, no definetely not. But due to this reason I stopped working on such bugs since a long time (was it nearly 2003-12?). So no need to bother, you are on the right way...
(In reply to comment #28) > (In reply to comment #26) > > We've shipped with the current UA since December of 2003 and I'm still happy > > with it and am not keen on changing it. I recognize that not everyone is happy > > with that :) > > Why not? It's cool short! I like the bug reports of people whose don't know > much about Thunderbird and their system. So you have to ask twice or more to > get the full information you need to start any qa work. That's not frustrating, > no definetely not. Yes, you are *ABSOLUTELY* right. Karsten also had this put quite nicely in his summary of comment #10: Summary: This current new form of the User-Agent header is now more readable for those who don't care about it anyway, but next to useless for those who depend upon it. It is hard for me to put it any better than Karsten had written it in April 2004 - about 19 months ago! Anyway, I'd still like to understand why the UA string had to be changed that way and why this malfunction cannot or "should not" be undone. Are there any reasons for this change? I mean - other than, that it now looks more ugly, than it did before?
*** Bug 325146 has been marked as a duplicate of this bug. ***
In any fix for this bug, please be sure the UA header appears on the [About > Thunderbird] window in a manner that can be marked and copied. By the way, the IETF link cited in comment #8 is now 404. Is there another reference? Has this become an RFC?
The cited link and section in comment #8 appears now to be <http://www.rfc-editor.org/internet-drafts/draft-ietf-usefor-usefor-11.txt> section 3.2.13. See also RFC 2616 at <ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt> section 14.43.
Taking off my radar.
Assignee: mnyromyr → mscott
Status: ASSIGNED → NEW
QA Contact: message-compose
(In reply to comment #26) > We've shipped with the current UA since December of 2003 and I'm still happy > with it and am not keen on changing it. I recognize that not everyone is happy > with that :) After ~2 years mscott is probably still happy with it ;) but if you want to have (for yourself or for the users you support) full UA string in TB then install Mnenhy extension - http://mnenhy.mozdev.org/ (fixed UA is only small part of it features).
Assignee: mscott → nobody
Severity: normal → enhancement
Summary: User-Agent Header should contain more information → User-Agent Header in About window should contain more information (complete user agent)
(In reply to comment #36) > *** Bug 426046 has been marked as a duplicate of this bug. *** While the About dialog was mentioned in some previous comment(s), let's not confuse the two issues: keep this bug for what TB adds to its email headers, keep bug 426046 for what it makes available in its About dialog. (And this goes for the two previous duplicates too.)
Summary: User-Agent Header in About window should contain more information (complete user agent) → "User-Agent" header, in sent messages, should contain more information
Version: unspecified → Trunk
Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.
Flags: wanted-thunderbird3.0a1? → wanted-thunderbird3.0a2?
Duping against 242361, since the patch there might even have a chance of being accepted...
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 242361
11 years ago
Status: RESOLVED → VERIFIED
(In reply to comment #39) > Duping against 242361, since the patch there might even have a chance of being > accepted... Patch didn't add anything what has not been before (cosmetic changes) so it can't be a duplicate (bug is still valid). -> Reopening
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
I don't see a compelling reason not to be more informative, and I can imagine it'd make support easier, so my vote would be to accept the patch.
So this has been suggested elsewhere (bug 446367). What I don't understand about the patch is why it doesn't just use the full user-agent string that Thunderbird already has (see currently nightly about dialog). I think in fact that's what we should do, and as Karsten suggested in bug 446367 comment 1: > Or you could just use the pHTTPHandler->GetUserAgent(userAgentString) call for > Shredder builds... (but I would make that all builds).
Lets get the patch cleaned up and move this in for b1
Priority: -- → P1
Target Milestone: --- → Thunderbird 3.0b1
(In reply to comment #43) > Lets get the patch cleaned up and move this in for b1 I'm not working on this, I gave it back long ago. Whoever feels the patch is useful as a base for his/her work, please feel free to mutilate it until it fits in. ;-)
Bryan wants to fix this bug, Magnus doesn't like the full UA (because its ugly), but here's my proposal for using the full UA anyway. Reasons: - We don't have to do any extra processing. - We automatically pick up any general.useragent.extra prefs (e.g. lightning) - Its the same as what we send for http, and therefore people know they can process it in the same way (if they really want to) - I'm thinking about people using this for support purposes. The UA we currently get is: - Thunderbird/version (note: always Thunderbird regardless of branding setting). - Platform - Full Build ID (not prefixed by Gecko) The full UA will give us additional info: - Mozilla/5.0 (although this is probably the one thing we don't need) - Language - OS/CPU - Gecko version - Correct name for Thunderbird (i.e. Shredder/Thunderbird) - Any extras that are included in the preferences by extensions or the user. Magnus, if you want to come up with another proposal, please do.
Well, seems to me the only missing (if you will) information is OS and language. Even the gecko id is in there implicitly. I wouldn't mind just adding those, along the lines of Karsten's earlier patch. I can offer to make a patch if we can agree on what we want it to look like. Re picking up general.useragent.extra prefs, I don't know why we would encourage extensions to put their name there just for the sake if it. Lightning does it but I got the impression that there wouldn't be so much of a Lightning extension in the future, just the lightning project, and a thunderbird (and possibly seamonkey later) where calendar is integrated. The current format on trunk is e.g. "Thunderbird/3.0b1pre (X11; 20080825035820)" I guess I propose we make that it read like e.g. "Thunderbird/3.0b1pre (X11; Linux i686; en-US; 20080825035820)" "Thunderbird/3.0b1pre (Windows; Windows NT 6.0; en-US; 20080825035820)"
(In reply to comment #46) > Well, seems to me the only missing (if you will) information is OS and > language. Even the gecko id is in there implicitly. I still think we should use the Shredder/Thunderbird name as well. > Re picking up general.useragent.extra prefs, I don't know why we would > encourage extensions to put their name there just for the sake if it. Lightning > does it but I got the impression that there wouldn't be so much of a Lightning > extension in the future, just the lightning project, and a thunderbird (and > possibly seamonkey later) where calendar is integrated. I'm not saying all extensions should do it, but I know a lot of extensions do, and I don't see why we should support something at http level and not support it in message headers where we are doing the same thing. > The current format on trunk is e.g. "Thunderbird/3.0b1pre (X11; > 20080825035820)" > > I guess I propose we make that it read like e.g. > "Thunderbird/3.0b1pre (X11; Linux i686; en-US; 20080825035820)" > "Thunderbird/3.0b1pre (Windows; Windows NT 6.0; en-US; 20080825035820)" I agree that's clearer than what we have in the full user-agent. I just don't see why we need the extra code to regenerate it in our own format. However, I think its time we had some comments from the other main developers on this.
Comment on attachment 335503 [details] [diff] [review] Just use the standard User-agent I don't see a lot of value in having this be "neater". It's only going to be used in a support context. I suppose it's conceivable that people might be able to talk about a neater version more casually to a support person rather than doing a full copy-paste, but I'm not sure that's particularly desirable. I suppose it's also the case that people doing software that handles email statistics might be forced to change their parsing code more than if we just added stuff here, but avoiding that doesn't feel like a particularly heavyweight benefit either. I'll cast my lot with code simplicity and matching user-agents between mail and http. That said, I'd like clarkbw to weigh in here in case there's some bit of UE-reasoning that I've missed. sr=dmose
I don't really see the user impact in sending a pretty string. I understand how magnus wants a nice looking UA, but that seems like it's more about the rendering end where we display the string. And I'd personally rather work on a string parser that allows us to display this header nicer than just text format (but that's just me).
Comment on attachment 335503 [details] [diff] [review] Just use the standard User-agent looks good to me
Attachment #335503 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 335503 [details] [diff] [review] Just use the standard User-agent r=me to paint it blue, purely because it's less code that way. Magnus and I will probably be happier once we turn off .showUserAgent and stop seeing how many Mozilla people use Mail.app, anyway.
Attachment #335503 - Flags: review?(philringnalda) → review+
Beating a dead horse, but what is the value of *not* having a pretty string - it was implemented for a reason back in bug 227863 (mail-agents do have pretty U-As). The code simplicity argument doesn't buy us much as it's already implemented and not very likely to break. With lightning installed the row is long enough (130+ chars) to make the whole Thunderbird string go off screen at times:(
So this would actually also go against RFC 2822, line length "SHOULD be no more than 78 characters".
(In reply to comment #52) > Beating a dead horse, but what is the value of *not* having a pretty string - A User-Agent header is not meant to be pretty but informative. Usually you don't display it, but check it for statistical or debugging purposes only. Only geeks like us care to see it. ;-) (In reply to comment #53) > So this would actually also go against RFC 2822, line length "SHOULD be no > more than 78 characters". That's quote abuse. :-P RfC 2822 says: "Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF." And: "The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC2821] if they actually cause information to be lost)."
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
(In reply to comment #48) > I suppose it's also the case that people doing software that handles email > statistics might be forced to change their parsing code more than if we just > added stuff here, but avoiding that doesn't feel like a particularly > heavyweight benefit either. Well, as SeaMonkey and Mozilla suite have been sending the standard UA string (which we're turning to again now) all the time, and e.g. the Mnenhy extension AFAIK has set back Thunderbird to that string as well, I guess people might already have the parsing in place for this.
(In reply to comment #52) > Beating a dead horse, but what is the value of *not* having a pretty string - > it was implemented for a reason back in bug 227863 (mail-agents do have pretty > U-As). The code simplicity argument doesn't buy us much as it's already > implemented and not very likely to break. It's less C++ code, so the attack surface is ever-so-slightly smaller, and there are ever-so-slightly fewer bytes in memory. Having the HTTP and Mail User-Agent fields be different also seems to violate the principle of least surprise. That said, I don't think the arguments in either direction are all that compelling, and related to that, I don't think it's really all that important which way this goes, but we do need _a_ decision. Given that we've reached agreement between the reviewers and ui-reviewer on this bug, I suggest not spending more time analyzing the exact result here.
Checked in, changeset id: 214:03c93f598af6 Fixed.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Verified with: User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080830025944 Shredder/3.0b1pre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080831032002 Shredder/3.0b1pre Mark, is the fix something we could also have for Thunderbird 2?
Status: RESOLVED → VERIFIED
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b1
(In reply to comment #58) > Mark, is the fix something we could also have for Thunderbird 2? I don't think that is necessary. TB 2 is essentially frozen and this fix wouldn't benefit it or anyone currently expecting there to be the old UA string - I think its ok to change the format between major versions, but not between minor versions.
This doesn't seem like an appropriate branch change, certainly not a "blocker". Will let dmose/dascher rule on approving a patch though.
Flags: blocking18.104.22.168? → blocking22.214.171.124-
I can't think of a compelling argument to change this in branch.
Just FYI: SpamAssassin checks for malformed User-Agent specs and assigns the mail a higher spam-likeliness score, if such a forgery is found. However, their check seems to be no problem with this change: header RATWARE_MOZ_MALFORMED User-Agent =~ /Mozilla\/5\.0\d\d/ describe RATWARE_MOZ_MALFORMED Bulk email fingerprint (Mozilla malformed) found If I read this right, the "malformed" rule only triggers, if there's a "Mozilla/5.014" (i.e. digits instead of a space after the "5.0"), so no problem.
I just checked in a change to remove the redundant addition of MOZ_APP_VERSION to DEFINES that was left when we did the patch (rs=Neil over irc): http://hg.mozilla.org/comm-central/rev/9441142c94d4
You need to log in before you can comment on or make changes to this bug.