>From an end-user's point of view, it could be much more relevant to get
on a
>wrong page, because than he knows he made a mistake in the url, while
if he
>gets nowhere, he may feel puzzled. What's wrong ? Url ? Network ?
Server
>down ?
I must politely disagree. If the server's down or unreachable, you'll
get a timeout, not an error from the server. Confusion due to server or
routing problems cannot be fixed by the client in any case. The only
situation the client can address is when the server returns something.

If the user gets back an arbitrary page, it may or may not be what he
wanted, he may or may not notice the difference, and if he does, he may
or may not attribute it to his URL mistake. A plain old 404 error tells
you exactly what's wrong, including the path as interpreted by the web
server. In other words, you get the information you need to fix your
error.

>This, obviously, is not true for all end-users.
I can't imagine it being true for anyone who's writing shell scripts.
Validation and error-trapping should be handled at the user interface
level.

Curl is reliable, it does one thing and does it well.

I don't want curl to "fix" urls for the same reason I don't want grep
to "fix" my regular expression, or cat to do spell checking.

>Wanting every one to learn, think and act properly is an unreachable
dream.
Of course, but there's a big difference between allowing people to make
mistakes and pretending that no mistake was made. Mistakes are how we
learn.

>-------------------------------
>Eric VERGNAUD - JLynx Software
>Cutting-edge technologies and
>services for software companies
>web: http://www.jlynx.com
>-------------------------------

Cheers,

Bill Mercer - National Center for Construction Education and Research
3600 NW 43rd St
Gainesville, Florida 32606
http://www.nccer.org
Phone 352-334-0911 Fax 352-334-0932
=============================================

                                       
Received on 2004-10-18