By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,230 Members | 2,427 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,230 IT Pros & Developers. It's quick & easy.

HELP - Re-direct based on OS

P: n/a
I am trying to create a site that will re-direct a user based on their OS.

For this site I will need to send NT4 and 95 users to site A and 2000/XP
users to site B.
All others should be directed to site B.

Thanks in advance.

Rich
Jul 23 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
navigator.userAgent will deliver some information about the used os

micha

Jul 23 '05 #2

P: n/a
alu
this should do the job, it actually discriminates between more platforms
than you require, just delete the unnecessary lines.
-alu
__________________________________________________ _
var n = navigator;
var ua = ' ' + n.userAgent.toLowerCase();

// find windows platform

var is_win = ua.indexOf('win') > 0;
var is_win16 = (ua.indexOf('16') > 0 && ua.indexOf('win') > 0);
var is_win31 = is_win16;
var is_win95 = (ua.indexOf('95') > 0 && ua.indexOf('win') > 0);
var is_win98 = (ua.indexOf('98') > 0 && ua.indexOf('win') > 0);
var is_winnt = (ua.indexOf('nt') > 0 && ua.indexOf('win') > 0);
var is_winnt4 = (ua.indexOf('nt 4.0') > 0 && ua.indexOf('win') > 0);
// go to yahoo if NT4 or win95, else go to Google

if(is_winnt4 || is_win95){document.location = "http://www.yahoo.com"}
else {document.location = "http://www.google.com"}
__________________________________________________ __

<Ri**@NeedsHelp.com> wrote in message news:q_***************@fe12.lga...
I am trying to create a site that will re-direct a user based on their OS.

For this site I will need to send NT4 and 95 users to site A and 2000/XP
users to site B.
All others should be directed to site B.

Thanks in advance.

Rich

Jul 23 '05 #3

P: n/a
alu wrote:
this should do the job, it actually discriminates between more
platforms than you require, just delete the unnecessary lines.
-alu
__________________________________________________ _
var n = navigator;
var ua = ' ' + n.userAgent.toLowerCase();

// find windows platform

var is_win = ua.indexOf('win') > 0; <snip> var is_winnt4 = (ua.indexOf('nt 4.0') > 0 && ua.indexOf('win') > 0);

<snip>

This appears to be based on the assumption that the userAgent property
of a browser's navigator object represents an accurate source of
information about the operating system on which the browser is running.
That assumption simply is not true.

Richard.
Jul 23 '05 #4

P: n/a
Ri**@NeedsHelp.com wrote:
I am trying to create a site that will re-direct a user based on their OS.

For this site I will need to send NT4 and 95 users to site A and 2000/XP
users to site B.
All others should be directed to site B.
<a href="siteA.html">NT4 and Win95 Users</a>
<a href="siteB.html">All other Users</a>

Anything else will fail.
Thanks in advance.


Welcome.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Jul 23 '05 #5

P: n/a
alu
Richard, I'm curious why that is - do some browsers disguise the platform,
or is userAgent not universal?
thanks
-alu
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:d5*******************@news.demon.co.uk...
alu wrote:
this should do the job, it actually discriminates between more
platforms than you require, just delete the unnecessary lines.
-alu
__________________________________________________ _
var n = navigator;
var ua = ' ' + n.userAgent.toLowerCase();

// find windows platform

var is_win = ua.indexOf('win') > 0;

<snip>
var is_winnt4 = (ua.indexOf('nt 4.0') > 0 && ua.indexOf('win') > 0);

<snip>

This appears to be based on the assumption that the userAgent property
of a browser's navigator object represents an accurate source of
information about the operating system on which the browser is running.
That assumption simply is not true.

Richard.

Jul 23 '05 #6

P: n/a
alu wrote:
Richard, I'm curious why that is - do some browsers
disguise the platform, or is userAgent not universal?

<snip>

The navigator.usetAgent property reflects the HTTP User Agent header.
That header is not subject to any stringent specifications as to its
contents and many browsers take the freedom that the HTTP specification
gives them as an opportunity to use completely fictitious User Agent
headers. And in addition to browsers that use fictitious User Agent
headers by default, I don't know of any browser where the User Agent
header is not user configurable to take any form the user chooses.

As a result no accurate information can be derived from the User Agent
header or the navigator.userAgent property (no matter how many people
don't know enough about the subject to be suggesting otherwise).

Richard.
Jul 23 '05 #7

P: n/a
Richard Cornford wrote:
As a result no accurate information can be derived from the User Agent
header or the navigator.userAgent property (no matter how many people
don't know enough about the subject to be suggesting otherwise).


If a user agent purposely supplies incorrect information, then the user of
that user agent should expect to get incorrect results.

If a browser supplies a meaningless or simplified User-Agent header, that's
one thing. If it masquerades as another browser, then it should expect to
experience quirks associated with that. If it knowingly supplies incorrect
information, then users should expect to see results consistent with that
incorrect information.

In much the same way, if a browser reported that document.getElementById was
available, but then failed when it was used, the script author couldn't be
held responsible for this. The browser supplied erroneous information.

There are a lot of things that could stop working correctly if browsers
decided to report incorrect information for the hell of it. What if the
browser reported that it could accept a certain type of response, but then
died when it was delivered? Would you say "don't trust the Accept header,
since browsers may report it incorrectly"?

Developers should never assume anything to be correct when dealing with
security and data integrity, or when collecting statistics. However, if the
browser reports its operating system to the server, and the server delivers
content customized for that operating system, and the content is incorrect,
then I fault the browser/user, not the developer.

From the HTTP Specs:

User-Agent:
This line if present gives the software program used by the original client.
This is for statistical purposes and the tracing of protocol violations. It
should be included. The first white space delimited word must be the
software product name, with an optional slash and version designator. Other
products which form part of the user agent may be put as separate words.

It doesn't say "fake this if you want to, therefore making this header
meaningless." If a browser reports an incorrect user agent string, then it
violates the very first sentence.

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #8

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
As a result no accurate information can be derived from the User Agent
header or the navigator.userAgent property (no matter how many people
don't know enough about the subject to be suggesting otherwise).

If a user agent purposely supplies incorrect information, then the user of
that user agent should expect to get incorrect results.


I can understand your argument Matt, but user agent and OS information
continues to be used to discriminate against visitors for totally
spurious reasons.

As a result, many 'minority' browsers can only get access to sites by
pretending to be what they aren't.

In that context, browser creators will continue to provide the
functionality for user agents to masquerade as whatever the user wants,
and therefore any assumption that a browser is what the user agent says
it is is likely to be wrong a significant proportion of the time.

[...] It doesn't say "fake this if you want to, therefore making this header
meaningless." If a browser reports an incorrect user agent string, then it
violates the very first sentence.


The downside of violating the specification for user agent string is
what? Messing up someone's stats?

The downside of strictly implementing the spec is being refused entry
to sites purely because you are using a UA other than one that the site
developer wishes you to use.

In the context of the 'browser wars' and wider scope of desktop OS
market share, the penalty for strict adherence was far greater than
any that could be derived from allowing users to set their own UA
string.

But having said all that, I think most new browsers do provide an
honest UA string by default (though many browser/OS sniffers to a
pretty crap job of interpreting them).

The OP is probably best to have something like "I think you are using
<insert reported OS here>, please follow <OS specific link>" and
provide alternatives in case it is incorrect.

--
Rob
Jul 23 '05 #9

P: n/a
RobG wrote:
I can understand your argument Matt, but user agent and OS
information continues to be used to discriminate against visitors
for totally spurious reasons.
I agree that this does happen sometimes, and it's a bad practice. I can
understand a browser masquerading as another more popular browser, but I
don't see why the OS should be faked. It could just be left blank.
The downside of violating the specification for user agent string is
what? Messing up someone's stats?
The downside could be that you receive content that doesn't apply to you.

For example, I worked on a company's intranet that did extensive browser
sniffing upon login. If it found that you were using a browser that needed
patches or updates, it gave you a direct link to the file on the fileserver
to get you updated. If your browser faked its UA header, you might be given
the wrong update file.

Of course, this was an intranet and a slightly different case, but it's an
example of when the user might get incorrect content because their browser
supplies incorrect information.
The downside of strictly implementing the spec is being refused entry
to sites purely because you are using a UA other than one that the
site developer wishes you to use.
Granted, from the user point of view it's a tough call sometimes.
The OP is probably best to have something like "I think you are using
<insert reported OS here>, please follow <OS specific link>" and
provide alternatives in case it is incorrect.


I agree with you there - use the UA string to provide a logical default
action, but always supply the user with other options in case your
assumptions based on UA are incorrect.

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #10

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
As a result no accurate information can be derived from
the User Agent header or the navigator.userAgent property
(no matter how many people don't know enough about the
subject to be suggesting otherwise).
If a user agent purposely supplies incorrect information,
then the user of that user agent should expect to get
incorrect results.


Information can only be incorrect where there is some means of
determining what correct information would be. All you are complaining
about here is information that is inconvenient to you, and it is
inconvenient to you because you have made an invalid assumption about
how meaningful that information is supposed to be.
If a browser supplies a meaningless or simplified
User-Agent header, that's one thing. If it masquerades
as another browser, then it should expect to experience
quirks associated with that.
It is always worth remembering that UA spoofing was started by Microsoft
and if they had not done so it may have been possible for the HTTP 1.1
spec to make some sort of strong requirement about the contents of the
header. As it is any consequences that follow from the sending of
User-Agent headers are the fault of anyone interested in those headers,
as they are labouring under an invalid assumption. The other browser
manufacturers cannot be considered at fault for following Microsoft,
motivated by exactly what motivated Microsoft to spoof Netscape in the
first place.
If it knowingly supplies
incorrect information, then users should expect to
see results consistent with that incorrect information.
Assuming a user with expectations related to the correct operation of
HTTP 1.1, it is not unreasonable to expect behaviour that conforms with
the standard for the protocol.
In much the same way, if a browser reported that
document.getElementById was available, but then failed when
it was used, the script author couldn't be held responsible for
this. The browser supplied erroneous information.
That would be a different situation. If the application of ECMAScript
operators and specified processes produced erroneous results when
applied to a DOM member than the browser's ECMAScript implementation
would not be a conforming ECMAScript implementation.

But the only significant failure of - document.getElementById -, in an
environment where feature detection verified the method's existence,
would be to throw on exception when called, which is objectively a
violation of the W3C Core DOM specification.
There are a lot of things that could stop working correctly if
browsers decided to report incorrect information for the hell of it.
But we are not talking about incorrect information where the User-Agent
header is concerned because there is no standard for correct
information.
What if the browser reported that it could accept a
certain type of response,
Like IE claming to accept *.*?
but then died when it was delivered?
IE handles the content types it asserts its acceptance of, but cannot
directly handle, by downloading them to disc. (does that qualify as
dying?)
Would you say "don't trust the Accept header,
I would recommend a big pinch of salt when presented with *.*.
since browsers may report it incorrectly"?
Some do. But the contents of Accept headers are well specified so they
are not equivalent situations. An Accept header may be objectively
malformed, but a User-Agent header cannot be.

<snip> However, if the browser reports its operating system
to the server,
Is the browser reporting its operating system to the server? Or is it
just sending a sequence of characters that should never have been
expected to convey meaning, and particularly not information (and
specifically not OS information)?
and the server delivers content customized for that
operating system,
Exactly what content needs customising to an operating system? Spyware?
viruses? Certainly not HTML, CSS, browser scripts, images, sound, flash,
video or Java applets.
and the content is incorrect, then I fault the browser/user,
not the developer.
No it is the fault of the developer for mistaking a meaningless sequence
of characters for a source of information.
From the HTTP Specs:
But which spec, you really should cite your sources.
User-Agent:
This line if present gives the software program used by the
original client. This is for statistical purposes and the
tracing of protocol violations. It should be included. The
first white space delimited word must be the software product
name, with an optional slash and version designator. Other
products which form part of the user agent may be put as
separate words.
So does this say anything about OS 'information'?

I assume this is from the HTTP 1.0 spec, the one Microsoft violated, and
continue to violate as the 'first white space delimited word' in their
default UA header is someone else's product name. So how many browsers
are there that send information that is 'correct' by HTTP 1.0? One;
Mozilla/Netscape/Gecko.

But moving up to date and looking at the HTTP 1.1 specification, and
starting with the official interpretation of the spec, we find:-

<quote cite="RFC 2616 Hypertext Transfer Protocol - HTTP/1.1">
1.2 Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [34].

An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for its protocols is said
to be "unconditionally compliant"; one that satisfies all the MUST
level requirements but not all the SHOULD level requirements for its
protocols is said to be "conditionally compliant."
</quote>

Which give us a list of significant key words to be used in interpreting
the specification, and particularly the User-Agent header section:-

<quote cite="RFC 2616 Hypertext Transfer Protocol - HTTP/1.1">
14.43 User-Agent

The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.
</quote>

- Where we find one occurrence of a key word. The word SHOULD in "User
agents SHOULD include this field with requests", and we know of no user
agents that do not send this filed with their requests so our formal
specification is satisfied.

When it comes to the contents of the header we find that the operative
word is "can"; "The field can contain ...". Not MUST, not even SHOULD,
but "can". It is not a key word in the specification and can only
reasonably be interpreted as a suggestion, the following of which is
completely optional.

The bottom line is that by the HTTP 1.1 specification the contents of
the User-Agent header are entirely at the discretion of the author of
the sending software. That software may send anything (so long as it
sends something) and be "unconditionally compliant" with HTTP 1.1.

If web developers fail to comprehend this, and make assumptions and
deductions based on the contents of the User-Agent header that is an
error on their part, and they are personally responsible for the
consequences of that error.
It doesn't say "fake this if you want to,
That is what the HTTP 1.1 specification does say (by placing no barrier
to doing precisely that).
therefore making this header meaningless."
If a browser reports an incorrect user agent string,
then it violates the very first sentence.


Even disregarding the current specification, where does it get you to
declare that the most common browser in use (IE) violates a
specification and sends 'incorrect information'? You still have
absolutely no realistic expectation of the User-Agent header containing
'correct information', and the HTTP 1.1 specification makes it explicit
that no such expectation should exist (which represents a useful
clarification of the position).

Richard.
Jul 23 '05 #11

P: n/a
RobG wrote:
Matt Kruse wrote: <snip> [...]
It doesn't say "fake this if you want to, therefore making
this header meaningless." If a browser reports an incorrect
user agent string, then it violates the very first sentence.
The downside of violating the specification for user agent
string is what? Messing up someone's stats?


Matt is being disingenuous in not citing which specification he was
quoting, the User-Agent header is not capable of violating the current
HTTP specification, as there is nothing to violate.

<snip> ... , I think most new browsers do provide an
honest UA string by default (though many browser/OS
sniffers to a pretty crap job of interpreting them).

<snip>

You really need to expose yourself to some more web browsers. I would
say that the majority of recent web browsers spoof IE's UA string by
default. I can't think of many PDA/Embedded browsers that do not (and
the majority of recently released browsers have been PDA/Embedded
browsers, as the rise of advanced mobile phones, etc, make that the
growing (and profitable) market).

Richard.
Jul 23 '05 #12

P: n/a
Richard Cornford wrote:
Is the browser reporting its operating system to the server? Or is it
just sending a sequence of characters that should never have been
expected to convey meaning, and particularly not information (and
specifically not OS information)?


Is "you're being obtuse" just a sequence of characters, or does it
intentionally convey meaning? If you take it as a statement of opinion about
your post, are you reading more into it than can be reliably determined?

The UA string has become a convention, a "de-facto standard". Not every
browser follows it, nor is any browser required to follow it. However, when
a browser _does_ follow the convention, and intentionally supplies erroneous
information, then a user of such a browser should expect to see results
consistent with what the browser reports.

A developer should never rely on this information as being correct. However,
making default decisions or guiding a user to the most appropriate
information based on what their browser reported certainly makes sense. As
long as there is an alternate path for the user in case the information
reported by the browser is not correct.

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #13

P: n/a
I guess I should have stated that the webpage will be hosted on a corporate
intranet where the standard image is Microsoft IE 5.5 v2 or higher. Other
browsers are not supported.
Jul 23 '05 #14

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
Is the browser reporting its operating system to the
server? Or is it just sending a sequence of characters
that should never have been expected to convey meaning,
and particularly not information (and specifically not
OS information)?
Is "you're being obtuse" just a sequence of characters,
or does it intentionally convey meaning?


I don't know, is it a sentence in the English language or the contents
of an HTTP 1.1 User-Agent header?
If you take it as a statement of opinion about
your post, are you reading more into it than can be
reliably determined?
It is ambiguous in the form presented.
The UA string has become a convention, a "de-facto standard".
I wouldn't argue with that. There is a de-facto standard, and Microsoft
established it, but it isn't the standard you think it is. The de-facto
standard for User-Agent headers is that whenever it is expedient to
place fictitious content in a User-Agent header it is acceptable to do
so. That describes the reality of the situation (currently and
historically).
Not every browser
follows it, nor is any browser required to follow it.
However, when a browser _does_ follow the convention, and
intentionally supplies erroneous information,
How can a browser both follow your de-facto standard and supply
erroneous information? All you are saying here is that you have an
expectation that a lie will take a form from which you can extract a
truth. But if that was a realistic expectation there would be no point
in telling lies in the first place.
then a user of such a browser should expect to
see results consistent with what the browser reports.
Why? The software receiving the User-Agent header has no reason to
deduce anything from that header (except that there is a user agent
making the request). There is no reason to expect the contents of the
header to make any difference to anything.

And if web developers want to disregard the HTTP 1.1 specification, and
ignore the normal, common and long established practice of browser
manufacturers (including Microsoft) then they are personally responsible
for the consequences of taking such an incompetent attitude. Not the
browsers, who are being "unconditionally compliant" with the spec, and
not the users of those "unconditionally compliant" browsers; the web
developers are at fault.
A developer should never rely on this information as
being correct.
The developer should not expect the 'information' to be meaningful.
However, making default decisions or guiding a user to
the most appropriate information based on what their
browser reported certainly makes sense.
Less sense than creating an interoperable system where the nature of the
user agent doesn't matter at all.
As long as there is an alternate path for the user in case
the information reported by the browser is not correct.


So that is a process of writing code to make deductions from meaningless
User-Agent header content, expending clock cycles running that code,
showing the user the results of that deduction (and looking foolish
whenever they are wrong) and then providing an interoperable alternative
to cover the inevitable shortcomings in the first stage?

As opposed to recognising that the nature of the user agent on the
public Internet is (and always will be) unknowable and writing one
interoperable system (with the technologies that have been designed to
be interoperable form the outset).

Richard.
Jul 23 '05 #15

P: n/a
Thanks Alu for your help. Just used a modified version of the script and it
is working.

var n = navigator;
var ua = ' ' + n.userAgent.toLowerCase();

// find windows platform

var is_win = ua.indexOf('win') > 0;
var is_winnt4 = (ua.indexOf('nt 4.0') > 0 && ua.indexOf('win') > 0);

if(is_winnt4){document.location = "nt.html"}
else {document.location = "xp.html"}
Jul 23 '05 #16

P: n/a
Ri**@NeedsHelp.com wrote:
Thanks Alu for your help. Just used a modified version of the script and it
is working.


Nah, you just think it works.

http://jibbering.com/faq/#FAQ4_26
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Jul 23 '05 #17

P: n/a
Actually it does work since the enviorment is all IE6 users (Corporate
Intranet). All users are on locked down systems. Only needed to redirect
NT users and 2000/XP users.
I had users on NT test and they were directed to the NT page and 2000/XP
users were directed to their page.

Rich
Jul 23 '05 #18

P: n/a
Richard Cornford wrote:
RobG wrote:
Matt Kruse wrote:
<snip>
[...]
It doesn't say "fake this if you want to, therefore making
this header meaningless." If a browser reports an incorrect
user agent string, then it violates the very first sentence.


The downside of violating the specification for user agent
string is what? Messing up someone's stats?

Matt is being disingenuous in not citing which specification he was
quoting, the User-Agent header is not capable of violating the current
HTTP specification, as there is nothing to violate.

<snip>
... , I think most new browsers do provide an
honest UA string by default (though many browser/OS
sniffers to a pretty crap job of interpreting them).


<snip>

You really need to expose yourself to some more web browsers.


Dang, and I thought there were laws against that sort of thing... :-x
I would
say that the majority of recent web browsers spoof IE's UA string by
default. I can't think of many PDA/Embedded browsers that do not (and
the majority of recently released browsers have been PDA/Embedded
browsers, as the rise of advanced mobile phones, etc, make that the
growing (and profitable) market).


The only reasonable purpose for a browser to fake the UA string of some
other browser is to avoid browser-based discrimination (leaving
developer and hacker considerations aside).

At a user level, this is fine - a user may want to to get access to a
site that does not behave when provided with the real string. But for
browser vendors/suppliers to fake another browser by default is crazy.

The effect of maybe a few hundred million (perhaps billions soon)
devices all saying they are IE or whatever when they aren't is to
reinforce its status as the 'de facto standard'.

The web is only just recovering from the last bout of 'IE-centricity'
that emerged from the browser wars - the last thing we need is
short-sighted vendors creating an environment where it can happen
all over again.

From a marketing/business sense, spoofing the UA string by default may
solve a problem in the short term, but in the long term it's utterly
counter-productive and potentially disastrous for the vendor. Given
the proven ability of players in various PC sectors to leverage market
share, they do not need the tacit approval of browser vendors to invade
and monopolise related markets for device OS and applications.

I hope that browsers will, by default, provide an accurate UA string
and only fake another browser when requested. The resulting user
involvement should ensure sites continue to be browser neutral to the
benefit of all web users.
--
Rob
Jul 23 '05 #19

P: n/a
RobG wrote:
Richard Cornford wrote: <snip>
I would say that the majority of recent web browsers
spoof IE's UA string by default. I can't think of many
PDA/Embedded browsers that do not (and the majority of
recently released browsers have been PDA/Embedded browsers,
as the rise of advanced mobile phones, etc, make that the
growing (and profitable) market).


The only reasonable purpose for a browser to fake the UA
string of some other browser is to avoid browser-based
discrimination ...

<snip>

Yes, that is why Microsoft introduced the practice, and why it is common
for others to follow them.
But for browser vendors/suppliers to fake another
browser by default is crazy.
It worked for Microsoft. If they had not spoofed Netscape their early
browsers would have looked broken (for no good reason) in a Netscape
dominated market place.

How does it become crazy for other browser manufacturers to do likewise.
The only difference is that these days it is most likely the non-IE
browsers that are going to be needlessly excluded for no good reason
(instead of the non-Netscape browsers), and there are slightly more web
developers about who recognise the folly in UA sniffing.
The effect of maybe a few hundred million (perhaps billions
soon) devices all saying they are IE or whatever when they
aren't is to reinforce its status as the 'de facto standard'.
It doesn't take a modicum of intelligent to see that when two distinct
user agents broadcast identical User-Agent headers it is impossible to
distinguish between them from those headers, and since there is no
specified reason to expect to be able to distinguish between them from
those headers nothing is lost. Except maybe a baseless belief that could
only be sustained by being blind to the reality.
The web is only just recovering from the last bout of
'IE-centricity' that emerged from the browser wars - the
last thing we need is short-sighted vendors creating an
environment where it can happen all over again.
User-Agent string sniffing has been (and still is) used to exclude
browsers that the writers of the UA string sniffing code don't recognise
(or don't approve of).

We find an example of exactly that mindset in this very thread, where
the exclusive list of operating systems sniffed from a UA string is the
list of Microsoft OS products. You might occasionally see unix/linux and
Mac OSs in such a list, but how many others, and especially PDA OSs will
be recognised and handled? (Are you in a position to name every OS
currently in use world-wide? No more than you are in a position to name
every browser in use.)

The manufacturer of a minor browser cannot expect their product to be
recognised by name (how many web authors are still convince that they
only have to deal with "both browsers"?) so if they admit the name they
will be excluded from some sites, resulting in their browser looking
broken to their uses. And no matter how good they make that browser, or
how slavishly they follow IE's proprietary features, or how standards
compliant their DOM and ECMAScript implementations are, their browser
will still look broken just because it admits its name. They are left in
the position where they con only fix their "broken browser" by using a
different name, so that is what they do (and that is what Microsoft did
in order to get its foothold in the market in the first place).

It is hardly realistic to suggest that a browser manufacturer
successfully releasing a working alternative web browser into the market
represents making it more 'IE-centric'. The worst that will happen is
that those foolish enough to take browser statistics at face value will
convince themselves that IE is more dominant than it really is. But the
believers in browser statistics are mostly interested in re-enforcing
their own personal prejudices so they would likely believe that anyway.
From a marketing/business sense, spoofing the UA string
by default may solve a problem in the short term, but in
the long term it's utterly counter-productive and potentially
disastrous for the vendor.
Why? The growing realisation that UA strings are not a source of
information will eventually render their contents irrelevant. The issue
is short term; dealing with the recalcitrant stub of incompetent web
developers who insist on taking action based upon the meaningless UA
strings. There will be no long term issue.
Given the proven ability of players in various PC sectors
to leverage market share, they do not need the tacit approval
of browser vendors to invade and monopolise related markets
for device OS and applications.
That reads like pure marketing BS. Do you have a real point to make?
I hope that browsers will, by default, provide an accurate UA
string and only fake another browser when requested.
You can hop as much as you like but the browser manufacturer are going
to be pragmatic, and while it is not in their interests to honestly
announce the make and version of their browsers they will not do so.
(And nobody has grounds for calling them wrong for following that line).
The resulting user involvement should ensure sites
continue to be browser neutral to the benefit of all
web users.


Which shows the whole UA string issue up for the nonsense it is. If you
write a browser neutral web site why would you need to care what
sequence of characters appeared in a User-Agent header?

It is only a desire to discriminate between browsers that justifies a
call for a mechanism for doing so, while the act of discriminating
justifies the sufferers from that discrimination undermining the
mechanism.

Richard.
Jul 23 '05 #20

P: n/a
JRS: In article <5A***************@fe12.lga>, dated Wed, 11 May 2005
15:32:19, seen in news:comp.lang.javascript, Ri**@NeedsHelp.com posted :
I guess I should have stated that the webpage will be hosted on a corporate
intranet where the standard image is Microsoft IE 5.5 v2 or higher. Other
browsers are not supported.

Certainly you should have.

The presumption in this newsgroup, which should be mentioned in the
regularly-posted FAQ, which you should have read, is that we are dealing
with construction of pages to be exposed to the public on the World Wide
Web.

Javascript for WSH, javascript for intranet pages, etc., can be
discussed but if that is the intent then the situation needs to be
clarified in the initial article and should be repeated in follow-ups.

On corporate machines, intranet or otherwise, the IT department may have
authority and control over all aspects of browser settings; in that
case, AFAICS, the IT department can cause the settings to indicate the
OS version truthfully.

It may be possible, I know not, to include at system set-up time, new
properties in the navigator object; in that case one could have
navigator.OStype set to, in your original terms, either A or B.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #21

P: n/a
Richard Cornford wrote:
As a result no accurate information can be derived from the User Agent
header or the navigator.userAgent property (no matter how many people
don't know enough about the subject to be suggesting otherwise).


A co-worker was just working on creating a more generalized "iframe shim" to
go behind DIV objects so that select objects and other items wouldn't bleed
through.

He only wants to use the iframe on IE on Windows, since that is the only
browser with the problem (and unfortunately, major market share).

Other than browser sniffing, what would be your solution to select only
IE/Win browsers to apply this fix to, or at least come as close as possible?

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #22

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
As a result no accurate information can be derived from
the User Agent header or the navigator.userAgent property
(no matter how many people don't know enough about the
subject to be suggesting otherwise).
A co-worker was just working on creating a more generalized
"iframe shim" to go behind DIV objects so that select objects
and other items wouldn't bleed through.


With the implication that these objects are going to be added, removed,
positioned and sized, else the issue doesn't apply.
He only wants to use the iframe on IE on Windows, since that
is the only browser with the problem (and unfortunately, major
market share).
The burn-through problem is a characteristic of the native Windows GUI
select (/combo box) widgets, it affects all windows browsers that use
the OS native widgets, to some degree.

But why try treat non-Windows IE differently, the hidden IFRAME will not
be harmful on other browsers and using the same code on all removes the
need to do a lot of branching in set-up and/or creation and
moving/positioning code. I would be inclined to regard a hidden IFRAME
as an opportunity; an available facility for doing cross-browser
background loading, equally useful on all browsers (that support dynamic
IFRAMES).
Other than browser sniffing,
Browser sniffing is academic in this context unless it is capable of
specifically discriminating Widows IE from other browsers. You aren't
going to be posting any code to demonstrate browser sniffing achieving
that, so it isn't a question of alternative approaches.
what would be your solution to select only IE/Win
browsers to apply this fix to, or at least come as
close as possible?


I wouldn't bother, indeed when I did precisely this task last year I
wrote one code that works identically on all of the dynamic visual
browsers capable of providing the facility. And the integrated
asynchronous background loading and call-back facility out performs the
SOAP/XMLHTTP request system in the same application, so we use it quite
a lot when SOAP use is not a necessity/requirement.

Richard.
Jul 23 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.