James wrote:
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.
