Closed Bug 29164 Opened 25 years ago Closed 25 years ago

user-agent has two Mozilla product tokens

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: cbegle, Assigned: jud)

Details

(Whiteboard: [PDT+] (since fix in hand))

here's our current user-agent User-Agent: Mozilla/5.0 (Windows; N; NT4.0; en-US) Mozilla/m13 BuildID: 20000224 There are two Mozilla product tokens. Can we have the m13 in the comment if we can't put it in the Mozilla version? The two Mozilla product tokens is just wrong.
well... I now look at the first (original UA string) as some opaque string that we don't even look at or care about. We can't change it. So, if we want to be inline with the new spec, this is how it is (note that the vendor token for netscape is "Netscape/6.0m14") if we want external parsers to start using our new values, we have to be consistent.
What new spec? We can change the string -- let's put the m13 in the comment. The comment is already different, since it has the language info in there. Adding another part to the comment is better than having two MOzilla product tokens, I think. The Gecko string, when it gets here, will make the string unique to Mozilla. At least, that was the intention of the document I wrote.
what I'm saying is that there aren't two product tokens. There's this *thing* up front that happens to have the text "Mozilla" in it. The Vendor token indicates an entity that is packaging the product (in this case Mozilla; in the commercial case "Netscape", in yahoo's case "Yahoo"). If we can pull this string out, then the "spec" is invalidated and my original point is proven (we don't need *any* of this extra stuff anyway :-). We put this string in so parsers could parse out the "vendor" of the client. If we don't specify the vendor when mozilla pushes a client out, but we do for everyone else, we've trashed our own spec (the one you put together).
Okay, I see where you're coming from, but I think you're wrong. :-) You have a token made up of "vendorShortName"/"vendorVersion". The spec has a token for VendorProductToken, *not* a vendor token. This is for products that are *based on Mozilla*, i.e., the "Netscape" in the user-agent for Netscape commercial builds does not refer the Vendor, it's the name of the product that's based on Mozilla. See the examples at the bottom of the document: A mozilla.org release Mozilla/5.001 (windows; U; NT4.0; en-us) Gecko/25250101 A branded release based on Mozilla/5.001 (Macintosh; N; PPC; ja) the same codebase as the Gecko/25250101 MegaCorpBrowser/1.0 (MegaCorp, Inc.) browser above Also, the spec has the VendorProductToken being optional, and used for products that are based on Mozilla. So removing this token does not invalidate the spec.
can we get this in for M14 please please please
but I just fixed another bug that you filed that asked me to do this??? I'm not touching the UA string again, until someone can come up with a coherent strategy.
jud, what i'm asking for is coherent with what i wrote before. what is it that you don't understand? the other bug is for Netscape; this is for Mozilla's user-agent string.
s/coherent/consistent
can one of you beat^H^H^H^H talk some sense into jud here?
no need. christine beat it into me. will fix this asap. putting beta1
Status: NEW → ASSIGNED
Keywords: beta1
waiting for review.
god-of-your-choice bless you jud valeski! p.s. one last thing.. when this gets reviewed can we get this fix onto the M14 branch?
PDT+ for beta1. M14 is a done deal... and should not be worked on. Land on the tip asap.
Whiteboard: [PDT+] (since fix in hand)
cbegle, if you want this one in M14, I'll land it there after Jud slams the tip. Jud, please reassign this to me (the irony) when you're into the tip.
Target Milestone: M14
so should we just stick the milestone in the misc field for Netscape too? This would leave the Netscape product token as "Netscape/6.0".
actually, don't answer that. I don't care. I don't have time for all the little details of this string. I'll maintain the code, but now that all the fields are prefs, someone else (christine? eric?) should adjust the values as necessary.
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified working winNT build 3/7/00
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.