Closed Bug 150351 Opened 19 years ago Closed 13 years ago

User-Agent: Add complete Build ID

Categories

(Core :: Layout, enhancement, P4)

enhancement

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: 3.14, Unassigned)

References

Details

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
Blocks: 71569
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..
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
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).
Status: RESOLVED → VERIFIED
Component: Networking → Networking: HTTP
QA Contact: benc → tever
Summary: Add complete Build ID to User-Agent → User-Agent: Add complete Build ID
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
also, i think there are some good arguments here about timezone considerations
and inconsistencies between the buildid and the UA string.

-> layout
Assignee: new-network-bugs → misc
Status: REOPENED → NEW
Component: Networking: HTTP → Layout: Misc Code
QA Contact: tever → nobody
Priority: -- → P4
Target Milestone: --- → Future
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.
Status: NEW → RESOLVED
Closed: 19 years ago13 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.