Browser Sniffing

J

James

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.
 
Y

Yann-Erwan Perio

James said:
I wasn't sure where to post this so I'm sorry if this is the wrong place.

You're at the right place, welcome on c.l.j:)
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.

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.
 
J

Jerry Park

James said:
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.
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.
 
L

Lasse Reichstein Nielsen

James said:
But I would like to know what some of the differences are between
client-side and server-side browser sniffing.

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.
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.

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
 
M

Mark Preston

James said:
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.
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.GetElementById" for
instance) check that the browser recognises. If - and only if - it
doesn't then code round it with what it can recognise.
 
S

Stephen Chalmers

Lasse Reichstein Nielsen said:
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.
What if a particular browser supports all required objects, yet has also a
known 'feature' that will cause a certain error?
 
S

Stephen Chalmers

Lasse Reichstein Nielsen said:
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.
What if a particular browser supports all required objects, yet has also a
known 'feature' that will cause a certain error?
 
J

Jim Ley

What if a particular browser supports all required objects, yet has also a
known 'feature' that will cause a certain error?

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

Jim.
 
S

Stephen Chalmers

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

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.
 
M

Matt Kruse

Stephen said:
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.

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 :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top