|Summary:||[mod_proxy] Apache reverse proxy status code transparency|
|Component:||mod_proxy_http||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description worx 2011-12-01 12:52:07 UTC
Created attachment 28011 [details] Txt Trace Hi, I have an Apache as an Reverse proxy. Client ------ HTTPS-----> Apache + Mod_proxy ------ HTTP ----> Webserver When the webserver send a response with HTTP status code 430, apache reverse proxy change this status code to 500. 401, 403, 404 status code are OK ! Thanks for your help ! Worx
Comment 1 Igor Galić 2011-12-02 10:24:26 UTC
This *should* be an easy fix. I had a brief look at the code in trunk and it's not obvious to me that it shouldn't work with trunk. To many negations: Can you please try trunk or 2.3.$latest and tell us if it works with that?
Comment 2 Ernst Lindoorn 2013-01-16 16:31:54 UTC
Any update on this issue? I can reproduce it with 2.4.3.
Comment 3 Ernst Lindoorn 2013-01-16 16:38:16 UTC
Our configuration (minimal settings) <VirtualHost *:80> ProxyPass /custom-errors/ ! ProxyPass / http://localhost:8080/ ProxyErrorOverride On ErrorDocument 500 /custom-errors/500.html </VirtualHost> If the backend server reponds with a custom error code (490 in our case) Apache changes that into 500 and shows the custom error page instead of communicating the error through the proxy.
Comment 4 Eric Covener 2013-01-17 14:28:39 UTC
(In reply to comment #3) > Our configuration (minimal settings) > <VirtualHost *:80> > ProxyPass /custom-errors/ ! > ProxyPass / http://localhost:8080/ > ProxyErrorOverride On > > ErrorDocument 500 /custom-errors/500.html > </VirtualHost> > > If the backend server reponds with a custom error code (490 in our case) > Apache changes that into 500 and shows the custom error page instead of > communicating the error through the proxy. Isn't that what you asked for with ProxyErrorOverride On? It doesn't just affect ones you've customized.
Comment 5 Ernst Lindoorn 2013-01-17 17:23:13 UTC
Hmm, ok it seems I misunderstood the functionality, I didn't realise it catches ALL error status codes.
Comment 6 William A. Rowe Jr. 2018-11-07 21:08:10 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.