Bug 49996 - Proxied ErrorDocument returns 200 OK response code
Summary: Proxied ErrorDocument returns 200 OK response code
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_http (show other bugs)
Version: 2.2.15
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks: 49997
  Show dependency tree
 
Reported: 2010-09-24 15:01 UTC by Luke Meyer
Modified: 2018-11-07 21:08 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Meyer 2010-09-24 15:01:54 UTC
I want to reverse proxy error documents from a backend server (to keep them consistent with the rest of the content/application proxied from there).

I tried the following reverse proxy configuration:
---------------------------
<Location /public>
   ProxyPass http://backend:8080/public
</Location>
ErrorDocument 404 /public/404.html
---------------------------
... with backend:8080 configured to serve up a valid 404 document for /public/404.html requests.

When I request a URL that does not exist on my reverse proxy, I get a 200 OK response instead of a 404 response code, along with the correct error document body from the backend. This is obviously confusing for caching, automation, etc.

Evidently with a ProxyPass the response code from the backend is used as the response code for the original request. Normally this would make sense, but not when a response code has already been set and we're just getting content to go with it. For reference, if instead we use a CGI script as the ErrorDocument and don't specify a new response code, the original response code is retained.

This suggests a relatively simple approach: upon returning successfully from a ProxyPass, check to see if the response already has a code, and leave it if so. AFAICS the only scenario where this would make a difference is the one I've described; in which case this handling offers the least surprising result.
Comment 1 William A. Rowe Jr. 2010-09-24 15:49:37 UTC
What about IgnoreErrorDocumentStatus on/off?

Better suggestions for the name?

There are legitimate reasons to use the result code of a crafty error document handler, so we need to distinguish between "here, have this status instead", and "ignore me, here's your error result text".
Comment 2 Luke Meyer 2010-09-28 14:42:25 UTC
(In reply to comment #1)

> There are legitimate reasons to use the result code of a crafty error document
> handler

Yes, but is there a reason for ProxyPass to overwrite an existing status code?

If there's to be a directive for this, then perhaps:

ErrorDocumentStatus keep (default override)
or
ErrorDocumentKeepStatus on (default off)

- so that it's clearly related to ErrorDocument and next to it in the docs.
Comment 3 William A. Rowe Jr. 2010-11-29 20:07:42 UTC
"is there a reason for ProxyPass to overwrite an existing status code?"

Yes.  The nature of the response defines what status it will present.

E.g. it is equally valid to present a redirect, or an OK document in response
to some error conditions.  This is all on the implementer to decide.

A new directive would give implementers more flexibility to avoid correcting
their obtuse cgi based or proxy based successful (200) error documents as
non-success pages.
Comment 4 William A. Rowe Jr. 2018-11-07 21:08:55 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.