404 versus custom error page?

[sinister]

I have some CGI programs that spit out error pages when the user enters
illegal form input. These custom error pages, while informing the user of
errors, are otherwise just standard web pages.

Is there a disadvantage to not spitting out a 404 error? I assume 404 isn't
just another webpage, but carries with it the information that an error
occured---in so simple a manner that it could be used for e.g. link
checking.

TIA,

S

[Anne van Kesteren]

sinister wrote:

[snip]

404 is a HTTP header, which should be sent when a file can't be found. I
think your error page has a different meaning.
--
Anne van Kesteren
<http://www.annevankesteren.nl/>

[Harlan Messinger]

"sinister" <si******@nospam.invalid> wrote in message
news:eA***************@nwrddc02.gnilink.net...

I have some CGI programs that spit out error pages when the user enters
illegal form input. These custom error pages, while informing the user of
errors, are otherwise just standard web pages.

Is there a disadvantage to not spitting out a 404 error? I assume 404 isn't just another webpage, but carries with it the information that an error
occured---in so simple a manner that it could be used for e.g. link
checking.

HTTP status codes are just that--HTTP status codes. They tell the browser
the outcome of its HTTP request for a resource (page, image file, whatever),
such as:

whether the resource is being returned as asked (200)

whether the browser needs to look elsewhere for the
resource it requested (a client-side redirect, 302)

whether the browser needs to be authenticated
before the page will be provided (401)

whether authentication has failed (403)

whether the URL refers to a non-existent resource (404)

In your situation, you are asking about an *application* error. There was no
*HTTP* error: the server correctly found the resource you requested, which
is, after all, the resource (web page) that determined that the form input
was bad. The correct HTTP status code to be return in this situation is 200.

[David Dorward]

sinister wrote:

I have some CGI programs that spit out error pages when the user enters
illegal form input. These custom error pages, while informing the user of
errors, are otherwise just standard web pages.

Is there a disadvantage to not spitting out a 404 error? I assume 404
isn't just another webpage, but carries with it the information that an
error occured---in so simple a manner that it could be used for e.g. link
checking.

404 says a _specific_ error has occurred, i.e. that the requested resource
could not be found.

You would be better of picking the appropriate error message for the
generated error.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

--
David Dorward <http://dorward.me.uk/>

[sinister]

"sinister" <si******@nospam.invalid> wrote in message
news:eA***************@nwrddc02.gnilink.net...

I have some CGI programs that spit out error pages when the user enters
illegal form input. These custom error pages, while informing the user of
errors, are otherwise just standard web pages.

Is there a disadvantage to not spitting out a 404 error? I assume 404 isn't just another webpage, but carries with it the information that an error
occured---in so simple a manner that it could be used for e.g. link
checking.

TIA,

S

Thanks to AVK, DD, HM for prompt, useful replies. (Seems to be a productive
group.)

[sinister]

"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:bq*************@ID-114100.news.uni-berlin.de...

"sinister" <si******@nospam.invalid> wrote in message
news:eA***************@nwrddc02.gnilink.net...

I have some CGI programs that spit out error pages when the user enters
illegal form input. These custom error pages, while informing the user of errors, are otherwise just standard web pages.

Is there a disadvantage to not spitting out a 404 error? I assume 404 isn't

just another webpage, but carries with it the information that an error
occured---in so simple a manner that it could be used for e.g. link
checking.

HTTP status codes are just that--HTTP status codes. They tell the browser
the outcome of its HTTP request for a resource (page, image file,

whatever), such as:

whether the resource is being returned as asked (200)

whether the browser needs to look elsewhere for the
resource it requested (a client-side redirect, 302)

whether the browser needs to be authenticated
before the page will be provided (401)

whether authentication has failed (403)

whether the URL refers to a non-existent resource (404)

In your situation, you are asking about an *application* error. There was no *HTTP* error: the server correctly found the resource you requested, which
is, after all, the resource (web page) that determined that the form input
was bad. The correct HTTP status code to be return in this situation is 200.

That sounds reasonable---it's not an HTTP error, so just return the
customized page as I've been doing.

Thanks.

[Tim]

On Wed, 3 Dec 2003 14:36:34 -0500,
"Harlan Messinger" <h.*********@comcast.net> wrote:

In your situation, you are asking about an *application* error. There was no
*HTTP* error: the server correctly found the resource you requested, which
is, after all, the resource (web page) that determined that the form input
was bad. The correct HTTP status code to be return in this situation is 200.

Or perhaps a different response, one indicating a user error, rather
than an all was fine response, when it wasn't.

Perhaps some of the other 400 series errors mentioned at:
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>?

e.g. 10.4.1 400 Bad Request

The request could not be understood by the server due
to malformed syntax. The client SHOULD NOT repeat the
request without modifications.

I suppose it'd depend on whether you considered a client's mistake to be
a creation of an "error" at the server, even if not an HTTP error.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Tim]

On Wed, 03 Dec 2003 19:12:10 GMT,
"sinister" <si******@nospam.invalid> wrote:

I have some CGI programs that spit out error pages when the user enters
illegal form input. These custom error pages, while informing the user of
errors, are otherwise just standard web pages.
Depending on the nature of the error, that'd be correct.
Is there a disadvantage to not spitting out a 404 error? I assume 404 isn't
just another webpage, but carries with it the information that an error
occurred---in so simple a manner that it could be used for e.g. link
checking.

A 404 response is a HTTP error message, which can also include a HTML
page (such as an explanation, or some help to work around the problem).

The 404 HTTP response is for the browser to know that an error has
occurred, and perhaps warn the surfer about it (it's also for the
benefit of any other non-web browser user-agent). The written HTML,
that may come with it, is for the surfer's benefit.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.

[Harlan Messinger]

"Tim" <ad***@sheerhell.lan> wrote in message
news:da********************************@4ax.com...

On Wed, 3 Dec 2003 14:36:34 -0500,
"Harlan Messinger" <h.*********@comcast.net> wrote:

In your situation, you are asking about an *application* error. There was no *HTTP* error: the server correctly found the resource you requested, which is, after all, the resource (web page) that determined that the form input was bad. The correct HTTP status code to be return in this situation is

200.
Or perhaps a different response, one indicating a user error, rather
than an all was fine response, when it wasn't.

Perhaps some of the other 400 series errors mentioned at:
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>?

e.g. 10.4.1 400 Bad Request

The request could not be understood by the server due
to malformed syntax. The client SHOULD NOT repeat the
request without modifications.
An HTTP 400 status code means that the server can't respond to the request.
In the case at hand, the HTTP request is fine and the server is responding
to it just fine, passing back to the client whatever stream the web resource
requested produces. The server understands the request just fine, and it
finds the page that is being requested.

Why would you *want* your user to see a generic 400 error instead of a
message produced by your application telling him what his error is and
giving him a chance to correct it?

I suppose it'd depend on whether you considered a client's mistake to be
a creation of an "error" at the server, even if not an HTTP error.

It isn't open to personal discretion. An error in data input to the
application is not an HTTP communication error. Of course, you can do what
you want. No one is going to put you in jail. I'm speaking in terms of the
correct use of the status codes.

[Alan J. Flavell]

On Fri, 5 Dec 2003, Harlan Messinger wrote:

It isn't open to personal discretion.
Hmmm...
An error in data input to the
application is not an HTTP communication error.

In the WWW *model* that we're discussing here, there _is_ no
"application" as such: there is a client, and it communicates with a
server black box by presenting an opaque token (the URL). The error
as communicated by HTTP is the final result of presenting that opaque
token to the black box.

Your "application" is no more than an internal detail of the server
implementation, as far as this WWW model is concerned.

I stand by my conclusion that if the server decides that a well-formed
request has been presented, but no productive content has been found
for fulfilling that request, then 404 is an approprate status return.
With, of course, appropriate body content to explain the situation.

The onus is on any WWW-conforming web client[1] to present that body
content to the client user.

cheers

[1] I guess we all know what that includes. And excludes.

[Harlan Messinger]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk...

On Fri, 5 Dec 2003, Harlan Messinger wrote:

It isn't open to personal discretion.
Hmmm...

An error in data input to the
application is not an HTTP communication error.

In the WWW *model* that we're discussing here, there _is_ no
"application" as such: there is a client, and it communicates with a
server black box by presenting an opaque token (the URL). The error
as communicated by HTTP is the final result of presenting that opaque
token to the black box.

Your "application" is no more than an internal detail of the server
implementation, as far as this WWW model is concerned.

I stand by my conclusion that if the server decides that a well-formed
request has been presented, but no productive content has been found
for fulfilling that request, then 404 is an approprate status return.

I think it's hard to argue that "not found" includes the case of "found, but
the resource that was found wishes it hadn't been" or "found, and wants to
send a response to the user, but wants to pretend that that response had
been pulled out of the server's hind quarters rather than having been
generated by the resource".

I'm not talking about *all* cases where an error was found by a process
sitting on top of the web server rather than by the web server itself. For
example, if you've got a content management system sitting on top of Apache
or IIS, and ask the CMS for a non-existent page:

http://www.cms.com/cms-process?page=108452

then the process *ought* to send 404.
With, of course, appropriate body content to explain the situation.

The onus is on any WWW-conforming web client[1] to present that body
content to the client user.

Actually, here's another approach to the question: what practical difference
would you expect in the result if a 404 was returned instead of a 200 in
response to invalid form data entry, if you are sending a body back with the
response either way? There ought to be a *point* to sending a 404. What
would you expect the browser to do differently? Why?

[Alan J. Flavell]

On Fri, 5 Dec 2003, Harlan Messinger wrote:

In the WWW *model* that we're discussing here, there _is_ no
"application" as such: there is a client, and it communicates with a
server black box by presenting an opaque token (the URL). The error
as communicated by HTTP is the final result of presenting that opaque
token to the black box.

[...] I think it's hard to argue that "not found" includes the case of "found, but
the resource that was found wishes it hadn't been"
You don't seem to have grasped the concept of the black box. The
requested resource was _not_ found. The fact that the CGI script was
invoked is a mere internal detail.

You might as well claim that a request for /foo/bar.html (assuming the
conventional static situation) was "found" if the corresponding foo
subdirectory was found, even though it didn't happen to contain the
file bar.html. It's still 404 not found.
Actually, here's another approach to the question: what practical
difference would you expect in the result if a 404 was returned
instead of a 200 in response to invalid form data entry, if you are
sending a body back with the response either way? There ought to be
a *point* to sending a 404. What would you expect the browser to do
differently? Why?

Hint: not all HTTP clients are browsers.

[Harlan Messinger]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk...

On Fri, 5 Dec 2003, Harlan Messinger wrote:

In the WWW *model* that we're discussing here, there _is_ no
"application" as such: there is a client, and it communicates with a
server black box by presenting an opaque token (the URL). The error
as communicated by HTTP is the final result of presenting that opaque
token to the black box. [...]

I think it's hard to argue that "not found" includes the case of "found,

but the resource that was found wishes it hadn't been"

You don't seem to have grasped the concept of the black box. The
requested resource was _not_ found.

Yes. It was.
The fact that the CGI script was
invoked is a mere internal detail.
No, it's not, because the CGI script produced a meaningful result that is
correct for the request.

You might as well claim that a request for /foo/bar.html (assuming the
conventional static situation) was "found" if the corresponding foo
subdirectory was found, even though it didn't happen to contain the
file bar.html. It's still 404 not found.
Not the same thing.

Actually, here's another approach to the question: what practical
difference would you expect in the result if a 404 was returned
instead of a 200 in response to invalid form data entry, if you are
sending a body back with the response either way? There ought to be
a *point* to sending a 404. What would you expect the browser to do
differently? Why?

Hint: not all HTTP clients are browsers.

How helpful is picking at my overly generic use of the word "browser" in
answering my question?

[David Dorward]

Harlan Messinger wrote:

Why would you *want* your user to see a generic 400 error instead of a
message produced by your application telling him what his error is and
giving him a chance to correct it?

There is nothing preventing one from sending an HTTP error code _and_ a
custom HTML document as the body part of the response (of course if the
body (including linked files - like images) is less then about 5k, MSIE
will decide its not helpful enough and replace it with a 'friendly' error
page - so include a nice image to boost the file size :D)

--
David Dorward <http://dorward.me.uk/>

[Harlan Messinger]

"David Dorward" <do*****@yahoo.com> wrote in message
news:bq*******************@news.demon.co.uk...

Harlan Messinger wrote:

Why would you *want* your user to see a generic 400 error instead of a
message produced by your application telling him what his error is and
giving him a chance to correct it?

There is nothing preventing one from sending an HTTP error code _and_ a
custom HTML document as the body part of the response (of course if the
body (including linked files - like images) is less then about 5k, MSIE
will decide its not helpful enough and replace it with a 'friendly' error
page - so include a nice image to boost the file size :D)

Is that how it works? So "friendly", those MS people.