Closed Bug 217407 Opened 22 years ago Closed 20 years ago

User-Agent String: Need Standard for Build Info (Format for vendorComment)

Categories

(Core :: Networking: HTTP, enhancement)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 274928

People

(Reporter: mozilla, Assigned: darin.moz)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Firebird/0.6.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Firebird/0.6.1+ There are different builds by different people floating around for Mozilla and Mozilla Firebird. There needs to be an easy and standardized way to signify whose build is being used and what special sauce that build uses (XFT, SVG, optimizations, etc.). The logical place to put such a standardized string seems to be in the vendorComment as per "http://www.mozilla.org/build/revised-user-agent-strings.html". This bug exists to come to a resolution on what such a standardized build info string would look like. Reproducible: Always Steps to Reproduce: One such format could be as simple as a link to some page describing the particular build in detail, such as a bugzilla entry, mozilla forums post, or someone web page. Another format could be the person's name and a small list of abbreviations, such as "pryan #12: GTK2 XFT SVG G7 O2". The #12 could be a reference to a particular mozconfig or anything else to precisely identify the build made by that builder. It could be optional.
Another format could be this: vendorComment = builder-ID (eg. "pryan") And then some detailed comments could be placed in a new section of about:buildconfig.
Seeing the additional comment I have to ask is the goal here to: - identify the build origin to end users - identify the build origin to external servers - identify the build capabilities to end users - identify the build capabilities to external servers
Re: Comment #2 Seeing the additional comment I have to ask is the goal here to: - identify the build origin to end users - identify the build origin to external servers - identify the build capabilities to end users - identify the build capabilities to external servers The goal I originally had in mind was two-fold: 1) Provide an easy way for users in the Mozilla Firebird Build Forum (http://forums.mozillazine.org/viewforum.php?f=23) to identify exactly which unofficial build they are using by having a standard way for builders to put differentiating information in the User-Agent string. 2) Provide an uniform way for end users to find out precise information about a particular build, or at least as much information as the builder wants to provide. So, the answer to your question is - identify the build origin to end users - identify the build capabilities to end users However, if there were a standard, then HTTP servers could make use of that information too, but that was not my intent when I filed this bug.
so how many non-standard builds are there really? seems like it'd be enough to add an identifying name in the vendor comment plus some identifying number. (pyran:16) where "16" would mean a particular build configuration. presumably the site from which the build originated could provide an index mapping "16" to a list of features. i don't think you want to use this vendorComment to identify supported features to websites. that is the job of things like the HTTP Accept header and other mechanisms.
Re: Comment #4 There are actually quite a few Mozilla Firebird builds (the Mozilla Firebird Build forums link to most of them, I'm sure), and I know there are several Mozilla builds too. I agree that there is no need to identify capabilities to web sites in the vendorComment, as there are other mechanisms in place for such things. <aside> I should point out that there is a report (http://forums.mozillazine.org/viewtopic.php?p=159765#159765) that the vendorComment string borks Mozilla Firebird when it is over a certain, seemingly short length. It should probably be a bug, now that I'm thinking about it. </aside> Thinking about it more, it would probably be best to leave out the mapping number and just rely on the description provided by the builder to create a precise mapping to the build config. (pryan:GTK2,XFT,SVG,O2) It would be even nicer to provide a space for a URL to the config and release notes for that build. Perhaps there is a place in about:buildconfig to place that URL? Or we could just rely on out-of-band information to convey the home of the build, such as a readme in the top-level directory. I don't like the idea of putting a URL in the User-Agent string. I do like the idea of having the vendorComment, a URL and possibly a builder-provided detailed description of the build in a section of about:buildconfig.
i would strongly advise against a lengthy vendorComment string. remember that every byte you add to the UA string is an extra byte that must be sent by the browser with every requested URL. and, that can really add up. the big issue is that there is a cost-jump when the entire HTTP request spills over into a second TCP packet. anyways, our UA string is already extremely bloated.. probably a good idea to not go overboard here :-/
Re: Comment #6 Good point about bandwidth usage. Why don't we go with this: (builder-ID:builder-Config-ID) e.g. (pryan:16) and then put some builder notes in about:buildconfig. Would that be reasonable?
>(pryan:GTK2,XFT,SVG,O2) Only SVG and mathml could be in the UA string but not the other options (XFT, GTK2, Pentium V super optimized,..) and SVG and mathml belongs in the requests header if we need to send this. If you want to add your own buildname into the UA,you should append it after the Gecko/build ID string (the Vendor ID belongs there) BTW:I would reduce the current UA (remove the crypto strenght, remove the rv: and also remove the 2 digits in the Build ID : 2003=03)
pyran: yes, i think that is reasonable. matti: yeah, our UA string does suck... maybe we need another bug for trimming those parts out. however, i suspect removing those parts is going to be pain.
> BTW:I would reduce the current UA (remove the crypto strenght, remove the rv: > and also remove the 2 digits in the Build ID : 2003=03) Matti, if you remove rv:, what noticable difference will be between trunk and branch builds of same date? If you reduce year, you probably break statistics/analysis of user browsers based on user-agent sniffing etc. If you change anything to save several bytes, you'll probably break applications you never heard about. There is some specification of user-agent string for Gecko based application, so follow it as long as is possible. Comment #7 looks good for me, but IMHO there isn't any reason (usefull for user) to put this kind of info to user-agent string.
Re: Comment #8 "If you want to add your own buildname into the UA,you should append it after the Gecko/build ID string (the Vendor ID belongs there)" Yes, normally, except Mozilla Firebird is using the vendorID already (see the User-Agent for this bug). Re: Comment #9 Ok, so this proposal looks good then. I have some changes to make it work better: 0) The builderID and builderConfigID entry is optional and up to the vendor (builder) in all cases. 1) We should switch from the colon format to the semi-colon format to maintain symmetry with the mozillaComment format. 2) When the vendorID is used but not the vendorComment, as is the case with Mozilla Firebird, then the builderID will be in the vendorComment in the form of "(builderID; buildConfigID)". This is a workaround for the special case of browsers like Mozilla Firebird that have used the vendorID but not the vendorComment. If the need arises to address the case where both vendorID and vendorComment are used, then this bug can be reopened. 3) When the vendorID field is not used, as is the case with Mozilla, then the builderID will be in the vendorID field in the form of "builderID/buildConfigID". This is the normal case. 4) There will be a new optional section to about:buildconfig where the builder can make notes about this build. This section will be called the "Vendor Notes" section of about:buildconfig. The builder/vendor can put things like a description, a URL for the builds, the mozconfig and any other notes about patches, optimizations, etc. Other than the name of the section, the contents are free-form. Re: Comment #10 "IMHO there isn't any reason (usefull for user) to put this kind of info to user-agent string." I see users pass around User-Agent strings to compare builds. They are important in bugzilla, and are in fact captured automatically when a bug is filed. They are captured automatically in some tech-help forums when posting, and on other websites. The User-Agent string is used as a unique token to identify a paticular build, but with so many builds out there, the current User-Agent string is not uniquely identifying builds.
Do we really want to touch the user-agent for branding purposes? How different would these builds be from each other that a website would need to check for a particular brand? If we're just talking about something that can be visibly identifiable by a human, we may just want to revisit the branding via the build id issue that we briefly touched upon in bug 26798. Or add a vendor string to about:buildconfig .
why is this needed? why does it need to be in the user agent? does every site visited need to know this stuff? is it a diagnostic? is it a popularity indicator? is it to help target plugins or extensions to a build? is it to help select the right quirky content for a build?
Re: Comment #12 This isn't for branding purposes. People use the User-Agent as a unique identifier for a build, but the User-Agent is not acting as a unique identifier currently. Having a unique User-Agent for each build on a given day by different people is invaluable for troubleshooting purposes. The combination of the proposed User-Agent and notes in about:buildconfig allow a user to know exactly where the build came from without having to spend time tracking down a build's origin via out-of-band channels. Re: Comment #13 "why is this needed? why does it need to be in the user agent?" People use the User-Agent string to identify builds. We could train users to tell the difference by placing that information in about:buildconfig, but then this complicates the work of troubleshooters who rely on the User-Agent string to tell exactly which build is causing the trouble (re: bugzilla, in the forums, developers, etc.). "does every site visited need to know this stuff?" No, but then again, there is stuff in the User-Agent currently that sites don't need to know (*Comments). This proposal is within the bounds of the User-Agent Strings document at http://www.mozilla.org/build/revised-user-agent-strings.html and merely sets a standard on which people can rely and builders can reference. "is it a diagnostic?" Yes. "is it a popularity indicator?" No, but it would end up being shown in statistics for web server logs and may prove useful in the future. "is it to help target plugins or extensions to a build?" No. "is it to help select the right quirky content for a build?" No.
IMHO, this should be in <about:buildconfig>, not user agent, and if the user doesn't know where the build came from, then he shouldn't be running it and even less so play a beta-tester. BTW: Firebird's UA is off. "Firebird" is not the vendor. (And what's that second "Mozilla" in there? Is that supposed to be Gecko->Mozilla->Firebird? Or "Mozilla Firebird", Version 0.6.1? The latter would be malformed per HTTP spec.)
Re: Comment #15 I agree with you about Mozilla Firebird's User-Agent being non-compliant. The User-Agent needs to be unique over different builds for the same day. People and websites, including bugzilla.mozilla.org, rely on the User-Agent being unique. People who use Mozilla aren't always the ones who installed it on their machines, or did so long enough ago to have forgotten where they grabbed it. There needs to be a differentiating string in the User-Agent, as per http://www.mozilla.org/build/revised-user-agent-strings.html. Not only that, having a unique User-Agent makes troubleshooting easier, opening the door for more testers and reducing the workload on people reviewing bugs and other troubleshooters. It is not a good idea to turn users away when it would be so easy to include them in the QA process.
According to the UA spec, vendorProductToken is a "product [token] for applications based on Mozilla." I'd argue that Firebird falls into this category. It does not have to be the name of the vendor responsible for the product. That said, I think "Mozilla Firebird/0.6.1" should be shorted to "Firebird/0.6.1" or at least we should remove the space between "Mozilla" and "Firebird."
> According to the UA spec, vendorProductToken is a "product [token] for > applications based on Mozilla." I'd argue that Firebird falls into this > category. I'd argue that the description in the "spec" is unfortunate. :-) "vendor" makes the intent quite clear IMHO, and Firebird is not a vendor version. What do I do, if I create a vendor version based on Firebird? That's quite likely, if Firebird will be the default mozilla.org product. I wonder, if we're getting offtopic, though.
Non-compliant Mozilla Firebird User-Agent (space in VendorProductToken) -> bug 217529.
Re: Comment #17 http://www.mozilla.org/build/revised-user-agent-strings.html allows for multiple VendorProductToken|VendorComment entries. "MozillaProductToken (MozillaComment) GeckoProductToken *(VendorProductToken|VendorComment)"
> The User-Agent needs to be unique over different builds for the same day. Oh, no it doesn't! The user agent is NOT for users, the user agent identifies the user's software to web servers. Do servers care about the difference between IE and Mozilla? Certainly. Between Mozilla and Gecko-based Galeon or Firebird? Mostly not because they work the same, though people are always curious so it can't hurt to distinguish if it doesn't cost much. When we first came up with the current compromise user agent we argued over the resolution of the Gecko token and agreed that resolution of one day is workable. There was a contingent that thought anything more fine-grained than milestone releases was a perversion of the UA intent, and another camp who wanted to use the full build string down to the hour. Turns out our own servers (bugzilla, primarily) benefit from date granularity on occassion so we went with that. The current UA is ugly, and if we were starting the UA from scratch there's a lot we could do differently. Even at the beginning of the Mozilla project, though, there were things we wanted to do different but were locked in by server expectation and that's only more true now. We can do anything we want, but aesthetic changes will come at a real-world-usability cost. We need to be very careful and conservative in changing the content and structure of the UA. When we invented the "vendor" token we were mainly thinking of re-branded Mozilla appsuites (that is, Netscape), but also non-Mozilla Gecko-derivatives like Galeon, K-meleon, and, we hoped, AOL. Note that "Netscape" is not just Mozilla built by someone else, it is a separate product with a different name and partially different features. Although at the time we didn't consider that mozilla.org would ship multiple Gecko-based products, Firebird, Thunderbird, et al fit reasonably well with the intent of the "vendor" field. You could come up with a different scheme such as putting "Firebird" in the Mozilla or Gecko comment fields, but since it's versioned it fits pretty nicely as a standard product token. If you need to designate the builder of the Firebird product then you could use the vendor comment field. Netscape's "Browser Distribution Project" allows people to ship modified (including re-branded) versions of Netscape, but requires that the modified builds be identified in the vendor comment. For example, Netscape/7.1 (CK-SillyDog), where "CK-" is a fixed string probably standing for "Customization Kit" or something. If someone is building a Firebird modified enough to be a new product then it should probably not be called Firdbird in the vendor token. If it's official Firebird source built by Joe Schmoe with zero modifications there's no need to identify that in the user agent -- it's of no interest to servers. Users may want to know, but there are better mechanisms than the user agent that gets sent with every HTTP transaction. The about: page comes to mind. about:buildconfig if you like, but that's pretty geeky if you expect users, as opposed to testers, to care. If there's some statistical good that comes from putting the builder in the vendor comment it would not be wrong to do, but remember the user agent is for servers, not for users. "Mozilla<space>Firebird" is wrong as has been pointed out: that would be a versionless second Mozilla product token followed by a separate Firebird product token. Since the beginning of the UA identifies it as "Mozilla" plain Firebird seems OK to me and would fit in with the RFC's pleas for brevity. But if we're still having fights with the DB people then you need a product token that does not contain control characters or any of the following: tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT Re: Matti's comment #8, two parts of the UA we probably cannot trim are the rv: portion and the current Gecko version format -- we know sites that avoid or use functionality based on those values. If we had the freedom to change them, or were willing to live with the pain, we would come up with something entirely different like Gecko/1.5b (bd:20030826) where the build date ("bd:") comment was provided in nightly test builds but not releases. Anyway, we have another bug for general discussion of what the UA should be. This bug is either a duplicate of that, or could be satisfied in quite a different way by beefing up about:buildconfig or inventing a standard mechanism to get build information included into the main about: page.
Re: Comment #21 Thank you for the great explaination. I would be satisfied with an entry in about:buildconfig titled "Vendor Notes" (or something along those lines) containing free-form notes. If the User-Agent string does not need to be unique over different builds in principle, then I will start encouraging people to not treat the User-Agent string as such. Should builders modify xpfe/global/buildconfig.html.in before starting the build? I also like the idea that if the browser were modified enough for a server to care but not enough to rebrand it then it would be prudent to put some information in the VendorComment along with adding an entry to about:buildconfig. Also, in the case calling for a VendorComment, it may also be a good idea to put something in about: but I have no thoughts about how that should be handled other than whatever would go there should be short. Should I come up with a patch for the revised user-agent strings page reflecting this discussion?
Just as a note, there was discussion about having the bugzilla helper automatically request the about:buildconfig info from all submitters. For bugzilla purposes, that's much more useful than sticking abbreviations in the UA string...
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
This was actually fixed by bug 274928.
Resolution: EXPIRED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.