ErrorDocument 'OK' behavior

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

The core and mod_cgi generate documents with the 'default'
response code - 200 OK is set before the handler is ever
invoked, or a non-200 code if they are handling an error.

This isn't true of some other modules, including mod_jk.
It's also not true of mod_cgi if the 'Status: 200' field
is passed to httpd.  In those cases, the "error" page returned
is a 200 OK, which is clearly wrong.

I was about to blame the design of mod_jk, however is there
any reason we shouldn't ensure this behavior, for httpd-2.1,
in the core http output filter?

I'll craft and commit such a patch after the next 1.3/2.0
releases, unless I anyone voices objections to re-overriding
the status, status_line values to their original error values.

Bill

Re: ErrorDocument 'OK' behavior

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 08:57 PM 7/12/2005, Joshua Slive wrote:
>William A. Rowe, Jr. wrote:
>>The core and mod_cgi generate documents with the 'default'
>>response code - 200 OK is set before the handler is ever
>>invoked, or a non-200 code if they are handling an error.
>>This isn't true of some other modules, including mod_jk.
>>It's also not true of mod_cgi if the 'Status: 200' field
>>is passed to httpd.  In those cases, the "error" page returned
>>is a 200 OK, which is clearly wrong.
>>I was about to blame the design of mod_jk, however is there
>>any reason we shouldn't ensure this behavior, for httpd-2.1,
>>in the core http output filter?
>>I'll craft and commit such a patch after the next 1.3/2.0
>>releases, unless I anyone voices objections to re-overriding
>>the status, status_line values to their original error values.
>
>I'm not sure that I understand your message.  But people do use mod_cgi to deliberatly change status codes on ErrorDocuments.  For example, and ErrorDocument 404 pointed at a CGI can be used to generate dynamic content only for URLs that don't map to filesystem objects.

Hmmm.  For the purposes of httpd-2.2 (I'm not asking about any
backporting to change expected behavior in 1.3/2.0) ...

... is this really the right mechanism?  Perhaps an additional arg
to ErrorDocument to set an explicit reaction?  E.g. turning a 404
into a 302, or providing a 'good' page 200 in place of a missing
page.  Or a generic arg which says respect the errordocument's
result code?

The side effects of such a handler are obviously dangerous
for web crawlers, since missing pages (in this example) might never
be struck from a given index or collection.

I can see how what you've described is incredibly useful, but
also note that simple content, e.g. replacing the stock error
text with a more informative .jsp page becomes very difficult;
the mod_jk + tomcat jsp engine always sets r->status to 200.

Bill

Re: ErrorDocument 'OK' behavior

[Joshua Slive <jo...@slive.ca>]

William A. Rowe, Jr. wrote:
> The core and mod_cgi generate documents with the 'default'
> response code - 200 OK is set before the handler is ever
> invoked, or a non-200 code if they are handling an error.
> 
> This isn't true of some other modules, including mod_jk.
> It's also not true of mod_cgi if the 'Status: 200' field
> is passed to httpd.  In those cases, the "error" page returned
> is a 200 OK, which is clearly wrong.
> 
> I was about to blame the design of mod_jk, however is there
> any reason we shouldn't ensure this behavior, for httpd-2.1,
> in the core http output filter?
> 
> I'll craft and commit such a patch after the next 1.3/2.0
> releases, unless I anyone voices objections to re-overriding
> the status, status_line values to their original error values.

I'm not sure that I understand your message.  But people do use mod_cgi 
to deliberatly change status codes on ErrorDocuments.  For example, and 
ErrorDocument 404 pointed at a CGI can be used to generate dynamic 
content only for URLs that don't map to filesystem objects.

Joshua.