phal said:
Hi all;
I code Perl for CGI, I using regular expression to check the validation
of user input, because the form is small and it run only from my own
computer, anyways if many people using my form, do you think it will be
slow due to Perl is run under server. How about using JavaSCript to
check validation for user input? Do you think it a bit faster?
I assume you mean "slow" because of the request, not the general speed of
the check, right?
On equal footing JavaScript will almost always be slower than PERL -
JavaScript carries a lot of baggage and is not as optimized for RegEx's as
Perl is. However in practice Perl runs on the server and is doing many more
tasks while the client is sitting spinning it's wheels - so JavaScript seems
much faster (it has a whole machine sitting there to do this little script
while the server might be doing dozens, or hundreds of requests at the same
time).
So - purely from a performance standpoint - JavaScript may be "faster". You
may eliminate a server request and provide the interface "instant feedback"
(although remember that you'll be delivering more script to the client which
slows things down some).
However it's not safer. Script can be disabled - which would eliminate your
checking completely. Since it runs on the client-side it can also be
modified to return incorrect results. In general you should consider
validations at every level of your application:
1) Client-side (JavaScript) validations improve the user experience but do
not protect the application. These are optional, but can greatly improve
the usability of your application.
2) Server-side (Perl, ColdFusion, ASP, etc) validations protect the
application from "bad" data. These prevent common attacks (SQL injection,
cross-site scripting) and prevent your application from failing due to bad
data (out of range numbers and dates for example). These are not optional
because no other layer of validation is assured to run. In other words the
application must protect itself because it can't trust anything else to do
it.
3) Persistence-layer (Database, LDAP, etc) validation protect the system
from storing "bad" data and allowing it to accumulate. This is needed to
protect your permanent information storage - there are few things so
damaging to a company than to discover that their data is corrupt. Many
people ignore this and say "the application will do it" but this is a
mistake: data has a way of getting around. Your application may very well
not be the only thing accessing the data - another application may need it
for example or somebody may use some provided management tool (SQL Server
Enterprise Manager for example). The data system should therefore protect
itself as much as possible.
Sorry for the lecture... but this stuff is commonly misunderstood. It's
best to get started on the right track in the first place than try to
retrofit things later.
Jim Davis
