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
