Browser Sniffing

**Yann-Erwan Perio** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

James wrote:
[color=blue]
> I wasn't sure where to post this so I'm sorry if this is the wrong place.[/color]

You're at the right place, welcome on c.l.j:-)
[color=blue]
> But I would like to know what some of the differences are between
> client-side and server-side browser sniffing. I'm aware the client-side
> stops certain errors being transmitted so saves on bandwidth and server-side
> my catch errors that are missed on the client-side.[/color]

You're mixing two things here:
- browser sniffing, which aims at determining which browser is in use,
in order to use the appropriate DOM in the script,
- form validation, which aims at validating inputs of a form prior to
processing the values.

[1] About form validation

Form validation is the process by which you validate that the inputs
submitted by the user are correct, in format and data. For instance,
this can include date validation, fields not empty, credit cards numbers
etc.

This form validation should be done client-side *and* server-side:
- client-side, because it indeed saves bandwidth and server processing,
but also gives an immediate feedback to the user about the errors he's done;
- server-side, because the user may have javascript disabled, or may
even trick your client-side check. Moreover, you can do some
data-related checks, checking if a value is in a list (for instance in a
SQL request).

[2] About browser sniffing

Browser sniffing is the process by which you try to determine which
browser the user is using, in order to use the appropriate DOM methods.

The basic idea behind browser sniffing is that there are a variety of
platforms existing, and that if we know the platform the user is using,
we know what DOM is available. While this thinking was reasonable in the
years where only IE/NN would exist, this doesn't apply anymore, with
more than 100 browsers being in use.

Server-side browser sniffing relies on the header sent by the browser to
response appropriate pages; the problem is that these headers may be
false, either because a user agent is spoofing them (afraid of being
excluded from the server's response) or because a proxy in-between is
spoofing them. This means that you cannot know for sure what browser is
in the end (all the more most headers spoofed would be IE's).

Client-side browser sniffing can be done in two ways: (1) user agent
string, subject to browser spoofing, and (2) object detection, studying
what objects are available to infer an existing DOM - but since lots of
browsers offer the same DOM, some of them even spoofing DOM
properties/methods which they cannot process, you'll see that you cannot
detect what user agent is in use.

However, detecting DOM features client-side should be enough, there's no
need to check if the browser behind is IE or Opera if the wanted method
is supported. The basic idea is that we don't care what user agent is at
the end, provided it supports the methods we want to use. If it doesn't,
then the script will fail inevitably (but you can manage client-side the
way it will fail, this is called "clean degradation").

HTH
Yep.

**Andrew Thompson** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

On Thu, 20 May 2004 12:02:20 +0200, Yann-Erwan Perio wrote:
[color=blue]
> Client-side browser sniffing can be done in two ways: (1) user agent
> string, subject to browser spoofing, and (2) object detection,..[/color]

I use the first method in a page here..
<http://www.physci.org/jvmclean.jsp?pt =js>
using the crudely hacked out script here..
<http://www.physci.org/files/mscheck.js>

Since the page could only give 'false positives'
(it looks for a combination of Win/IE), I feel
it cannot do that much harm.

AFAIU.. the UA string spoofing comes
from users deliberately changing it.

Is that correct?

If that *is* the case, I figure there are few
who would be fooled when they came to the
page and saw the message 'This PC is running
Microsoft Windows and using Internet Explorer.
It is potentially at high risk...'

[ ..there are other, more detailed checks
done as well, before I recommend the user
download JVMClean to rid their PC of the
problematic MSVM in any case. ]

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

**Jerry Park** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

James wrote:
[color=blue]
>I wasn't sure where to post this so I'm sorry if this is the wrong place.
>
>But I would like to know what some of the differences are between
>client-side and server-side browser sniffing. I'm aware the client-side
>stops certain errors being transmitted so saves on bandwidth and server-side
>my catch errors that are missed on the client-side.
>
>Anything else would be great.
>
>Thanks.
>
>
>
>[/color]
You are much better off writing to standards and never browser sniffing.

It is extremely irritating to be told I can't use a site because I don't
use (whatever) browser. I can easily tell my browser to tell your site
that is is (whatever you want it to be). But if I have to do that,
unless I must use your site, I won't.

**Lasse Reichstein Nielsen** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

"James" <nospamheredude @yahoo.com> writes:
[color=blue]
> But I would like to know what some of the differences are between
> client-side and server-side browser sniffing.[/color]

The big difference is ofcourse the available information.

On the server, the only available information is the UserAgent header,
which many people are faking.

On the client, you can (try to) detect which features are available.
It is still not a safe method, since it requires total knowledge of
all browsers, current and future, that will access the page.

In any case, you must be prepared for browser-sniffing to fail, and
must decide what failure rate is acceptable and how to recover from
a failure.

This is why browser sniffing is not recommended, and feature detection
is, when it comes to making cross browser compatible scripts.
[color=blue]
> I'm aware the client-side stops certain errors being transmitted so
> saves on bandwidth and server-side my catch errors that are missed
> on the client-side.[/color]

That would be for normal validation: test on the client to prevent
a roundtrip to the server that would just report an error anyway,
and always test on the server.

For detecting the browser type/version, the client is better suited,
but still not very good. It is better to user feature detection on
the client for the features that one need, and don't bother detecting
the browser at all.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Jim Ley** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

On Thu, 20 May 2004 11:14:15 GMT, Andrew Thompson
<SeeMySites@www .invalid> wrote:
[color=blue]
>AFAIU.. the UA string spoofing comes
>from users deliberately changing it.
>
>Is that correct?[/color]

Nope, lots of UA's ship ready spoofed.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Mark Preston** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

James wrote:[color=blue]
> I wasn't sure where to post this so I'm sorry if this is the wrong place.
>
> But I would like to know what some of the differences are between
> client-side and server-side browser sniffing. I'm aware the client-side
> stops certain errors being transmitted so saves on bandwidth and server-side
> my catch errors that are missed on the client-side.
>
> Anything else would be great.
>[/color]
You are in the right place - but the wrong idea.

Don't "sniff" at all - write to the standards and before you use
anything that could be risky (like "document.GetEl ementById" for
instance) check that the browser recognises. If - and only if - it
doesn't then code round it with what it can recognise.

**Stephen Chalmers** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:k6z7ibdf.f sf@hotpop.com.. .[color=blue]
> It is better to user feature detection on
> the client for the features that one need, and don't bother detecting
> the browser at all.
>
>[/color]
What if a particular browser supports all required objects, yet has also a
known 'feature' that will cause a certain error?

--
SC

**Stephen Chalmers** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:k6z7ibdf.f sf@hotpop.com.. .[color=blue]
> It is better to user feature detection on
> the client for the features that one need, and don't bother detecting
> the browser at all.
>
>[/color]
What if a particular browser supports all required objects, yet has also a
known 'feature' that will cause a certain error?

--
SC

**Jim Ley** · Jul 23 '05, 11:06 AM

Re: Browser Sniffing

On Thu, 20 May 2004 14:17:00 +0100, "Stephen Chalmers" <me@here.com>
wrote:
[color=blue]
>
>"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
>news:k6z7ibdf. fsf@hotpop.com. ..[color=green]
>> It is better to user feature detection on
>> the client for the features that one need, and don't bother detecting
>> the browser at all.
>>
>>[/color]
>What if a particular browser supports all required objects, yet has also a
>known 'feature' that will cause a certain error?[/color]

Detect it - depending on the error you can generally do this, which
error did you have in mind?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Stephen Chalmers** · Jul 23 '05, 11:07 AM

Re: Browser Sniffing

"Jim Ley" <jim@jibbering. com> wrote in message
news:40acb1d3.4 27411595@news.i ndividual.net.. .[color=blue][color=green][color=darkred]
> >>
> >>[/color]
> >What if a particular browser supports all required objects, yet has also[/color][/color]
a[color=blue][color=green]
> >known 'feature' that will cause a certain error?[/color]
>
> Detect it - depending on the error you can generally do this, which
> error did you have in mind?[/color]

Obviously - except when there's no way so to do. I was thinking mainly in
terms of Opera and some of its now mostly extinct problems. These ranged
from trivial display problems, to things like failure to print initially
hidden layers, then more seriously a version in which any call to
setInterval would disable all links on the page. Detecting these problems
with script was beyond me.
I wrote a page intended to be saved locally, only to discover that Opera did
not support cookies created by local pages. Of course this can be easily
detected, but still requires an explanation to the user who would expect it
to work. I like to think my nagging played a part in having that fixed.
By all means try to detect it, but there'll always be times you can't.
--
S.C.

**Matt Kruse** · Jul 23 '05, 11:07 AM

Re: Browser Sniffing

Stephen Chalmers wrote:[color=blue]
> Obviously - except when there's no way so to do. I was thinking
> mainly in terms of Opera and some of its now mostly extinct problems.[/color]

Thank god for Opera7! It's finally useable, IMO.
Previous versions suffered from such inexplicable bugs and quirks that it
made it difficult to script for them.
Opera7 finally seems stable and good. But I still prefer Firefox :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

Browser Sniffing

Browser Sniffing

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment