Closed Bug 10379 Opened 21 years ago Closed 21 years ago

No User Agents for Necko Builds

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: paulmac, Assigned: jud)

Details

(Whiteboard: will attempt to verify when release builds available)

There is no useragent for the Necko builds, as of the Wednesday evenings builds
located at
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-07-21-16-M9-NECK
O/

You can see this at http://makeda/tests/mocha/objects/navigator/nav.html

Non-necko builds give a user-agent of Mozilla/5.0 [en] (Win95; I)

Certain pages, such as Netcenter Registration, check for useragents.

This is xp.
I've got some code that sets the user agent now (I'll be checking in shortly).
However, I've hardcoded all the strings <

#ifdef XP_MAC
    mAppPlatform = new nsString2("Mac", eOneByte);
#elif WIN32
    mAppPlatform = new nsString2("Win32", eOneByte);
#else
    mAppPlatform = new nsString2("Unix", eOneByte);
#endif
>

NOTE: these are the platform strings. I've also hardcoded language and security
level strings.

which is obviously the wrong thing to do, but, this is just to get us going. The
useragent construction stuff is a total mess. There are dozens of places where
people are accessing the old global UA compoent variables (defined in mkhttp.c).
There are even some fragments that construct the UA on their own rather than
going through the consistent GetUserAgent method.

We can either continue down the global variable road, in which case we have
completely screwed up link dependencies in order for all the users of the global
vars to be able to link. Or we can build up some lightweight service which each
platform implements. This service would provide all the platform specific stuff
that goes into a UA string.

We could have the modules that init these strings just conjure up the
nsIIOService and set these fields, but what kind of authorization issues do we
confront. We don't want an arbitrary module to have the ability to completely
modify the UA string.
I've got some code that sets the user agent now (I'll be checking in shortly).
However, I've hardcoded all the strings <

#ifdef XP_MAC
    mAppPlatform = new nsString2("Mac", eOneByte);
#elif WIN32
    mAppPlatform = new nsString2("Win32", eOneByte);
#else
    mAppPlatform = new nsString2("Unix", eOneByte);
#endif
>

NOTE: these are the platform strings. I've also hardcoded language and security
level strings.

which is obviously the wrong thing to do, but, this is just to get us going. The
useragent construction stuff is a total mess. There are dozens of places where
people are accessing the old global UA compoent variables (defined in mkhttp.c).
There are even some fragments that construct the UA on their own rather than
going through the consistent GetUserAgent method.

We can either continue down the global variable road, in which case we have
completely screwed up link dependencies in order for all the users of the global
vars to be able to link. Or we can build up some lightweight service which each
platform implements. This service would provide all the platform specific stuff
that goes into a UA string.

We could have the modules that init these strings just conjure up the
nsIIOService and set these fields, but what kind of authorization issues do we
confront. We don't want an arbitrary module to have the ability to completely
modify the UA string.
maybe this data can be stored in the registry?
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
we now send user agents. the fact that we're not sending the correct user agents
is reflected in bug 10465.
Whiteboard: will attempt to verify when release builds available
Status: RESOLVED → VERIFIED
verified on mac/linux/windows
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
You need to log in before you can comment on or make changes to this bug.