Currently a user-agent looks like this Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a) Gecko/20020607 on a mozilla with build id 2002060704, so the 04 is missing from the user-agent string. pi

Well, correct. This is according to http://mozilla.org/build/revised-user-agent-strings.html... Why do you want this to change?

-> wontfix the spec is : Date in the format YYYYMMDD no web-page needs the pull-hour. We need the day because we can disable some bad builds for bugzilla etc..

I tracked down a bug to the version which introduced it. So I found the need to clearly identify the tested versions. A user-agent would be handy. As Matti says, we can use it to block broken versions. Since there can be more than one version a day we should be able to tell them apart. pi

ask for a build ID from the title and block all builöds from the day BTW: there are 24 possible different build version / day

> ask for a build ID from the title Of course, but it would be very handy to have it in one place. > and block all builöds from the day Why, if less will do? > BTW: there are 24 possible different build version / day So? If there are different versions, it makes sense to clearly distinguish them. pi

Also, the Build ID does not say much. You cannot tell from it if it is branch or trunk, you cannot tell the OS. So there is no one identifier which says it all. pi

This is a really good bug, although I don't know if it is feasable. I learned long ago that UA strings are pretty established. However, I think the general idea, the need for a general, build-tracking (build-recognizing) mechanism is sound. -> HTTP Perhaps we could start sending a new header line (X-Mozilla-build: xxxxxxxxxx)? This would sites interested in tracking this information to be able to do so. Since the Mozilla builds are for testing and not a product per-say, we have more flexibility. It would also allow us to handle build-specific situations more accurately, I recently read an old bug where one build was holding open connections to one site, creating a denial of service situation. Offering build-specific information would very useful. Since UA issues draw a lot of bug activity, we should probably let this bug stay a UA bug (reasons why UA doens't have build ID), and create a new bug if there is sufficient interest. If someone creates a new bug, VERIFY this as WONTFIX... (cc'd some people that might also want to decide about this).

the UA string does contain the build date, for example: "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020528 Netscape/7.0b1" notice "Gecko/20020528" indicates the day on which Netscape 7.0PR1 was built. and "rv:1.0.0" indicates the mozilla branch. so, what am i missing? i can't think of anything more that should be needed to uniquely identify the browser build.

Darin, I use the following user-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a) Gecko/20020610 My build ID is 2002061004 So the difference is the hour. As there can be more than one build on a day I think we should be able to distinugish those. pi

pi: ok, i should have read this bug report more carefully :P anyhow, i don't really think there's all that much benefit to reporting the build hour. can you think of a time when having the time-of-day included in the UA would have actually helped or solved some problem that otherwise wasn't solvable? i mean, we've done ok so far as is, right? without some real-world examples compelling us to change our UA, i can't really justify the change. i think that's why this bug is best marked WONTFIX.

I submitted this bug after an extensive search for a regression. I installed more than ten version that day and took notes about the behavior. At some point I noticed that I missed the exact versions I used. To reconstruct I looked at what was marked as visited in the nightly directory. pi

Darin, it's more complicated than just that. I built my own Mozilla last night (my timezone); that's about 18 hours ago. The build id is 2002-06-11-20 (where the "20" is once again *my* timezone, GMT +1, and it would read "11" if it was built the same time at Mountain View). The UA string, though, says Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020609, so it's two days behind. If Boris were to block my build, he would probably block "20020611" in the UA string, and thus, my build *wouldn't* be blocked.

*** Bug 151776 has been marked as a duplicate of this bug. ***

For that we have (fortunately) different timezones in which people are compiling Mozilla, I think it would be a good idea to have a standard for the Build ID. GMT would do fine and would also resolve the hour-on-build-ID issue. Therefore I think WONTFIX is not OK. And the bug is not limited to HTTP networking. Please look over it again. \V/ Live long and prosper PointedEars

reopening... for some reason i didn't realize this earlier, but this part of the UA string is actually set by Layout (see content/build/nsContentHTTPStartup.cpp), so this is not at all a networking bug.

also, i think there are some good arguments here about timezone considerations and inconsistencies between the buildid and the UA string. -> layout

My understanding is that the ten digit build ID is set by bdate.pl and the eight digit Gecko version (build date) is set by gbdate.pl. Both scripts will look at MOZ_BUILD_DATE environment variable so the build ID and the Gecko build date can be synchronized. But they can also be out of sync. I self-build (mainly for SVG but also for other reasons) and the build ID is defaulted to "0000000000". The Gecko build date when self-building defaults to the date the tree was first built, and thereafter does not change (even if updates are pulled from the CVS tree) unless gbdate.pl is updated (or touched). I agree with the reasons given for using the same ten digit string, to include the hour, in the user agent. Then the build ID and the Gecko build date can be, but dont have to be, the same thing. I havent seen mention as to why the hour was included in the build ID but not in the Gecko build date. But it seems that if it is important enough to include the hour in the build ID then its important enough to include in the Gecko build date and thereby the user agent string, particularly when the whole lot is actually updated and built at the same time. I've read through a number of user agent/build id bugs, past discussion about user agent in n.p.m.seamonkey and http://www.mozilla.org/build/revised-user-agent-strings.html. Lots of past history on this topic.

The hour was added on the trunk some time ago by bug 383167.