You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modproxy-dev@apache.org by Ian Holsman <ia...@cnet.com> on 2001/09/18 19:55:58 UTC

handling 404's in reverse proxy.

just wondering what people's position is on this one.

should we be masking error pages coming from the reverse proxy
with the 'standard' server responses from the main server.

we really need to do something when we are using mod-include to include
a reverse proxied subcomponent.
at the moment it will show the 404 page from the r-proxy server.
if we try to include a normal file, we get the SSI error message
'[error]'.

I'm proposing that proxy-http does the same thing, and mask the
errorpages returned from the appserver
-- 
Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608


Re: handling 404's in reverse proxy.

Posted by Chuck Murcko <ch...@topsail.org>.
+1 for a start. Graham's suggestion of customized returned page with 
this as default behavior looks great in the longer term.

Chuck

On Tuesday, September 18, 2001, at 04:47 PM, Ian Holsman wrote:

> On Tue, 2001-09-18 at 11:57, Graham Leggett wrote:
>> Ian Holsman wrote:
>>
>>> just wondering what people's position is on this one.
>>>
>>> should we be masking error pages coming from the reverse proxy
>>> with the 'standard' server responses from the main server.
>>>
>>> we really need to do something when we are using mod-include to
>> include
>>> a reverse proxied subcomponent.
>>> at the moment it will show the 404 page from the r-proxy server.
>>> if we try to include a normal file, we get the SSI error message
>>> '[error]'.
>>>
>>> I'm proposing that proxy-http does the same thing, and mask the
>>> errorpages returned from the appserver
>>
>> MSIE has this behavior - and it's bogus. A replacement 404 page could
>> mask the real content that is returned that could be more useful.
>>
>> I have seen some people ask for this behavior though and yes, in some
>> cases it can be useful - at best it should be possible to enable 404
>> replacement with a config directive, but it definitely shouldn't be the
>> default.
>
> The other problem I'm seeing at the moment is when the page being
> requested is a r-proxy.
>
> <html>
> <!--#include virtual="/pma/404.html"-->
> </html>
>
> IF /pma/404.html is handled by the default handler (and is missing)
> I get the standard "[an error occured...]"
>
> IF the /pma/ is proxypassed it shows the 404 page of the other server.
> This behavior is should NOT be the default behavior, it should be the
> "[an error occured]".
>
> Oh..
> does anyone have any objections to the following patch.
> it just passes the error code of the proxied request instead of
> passing a '200' all the time.
>
> I think this should be fixed regardless.
>
>
> Index: proxy_http.c
> ===================================================================
> RCS file: /home/cvs/httpd-proxy/module-2.0/proxy_http.c,v
> retrieving revision 1.94
> diff -u -u -r1.94 proxy_http.c
> --- proxy_http.c	2001/08/30 19:48:02	1.94
> +++ proxy_http.c	2001/09/18 20:39:24
> @@ -850,7 +850,7 @@
>                           "proxy: header only");
>          }
>      }
> -    return OK;
> +    return r->status;
>  }
>
>  static
> @@ -954,6 +954,7 @@
>      status = ap_proxy_http_process_response(p, r, p_conn, origin,
> backend, conf,
>                                              bb, server_portstr);
>      if ( status != OK ) {
> +        ap_proxy_http_cleanup(r, p_conn, backend);
>          return status;
>      }
>

Chuck Murcko
Topsail Group
http://www.topsail.org/

Re: handling 404's in reverse proxy.

Posted by Ian Holsman <ia...@cnet.com>.
On Tue, 2001-09-18 at 11:57, Graham Leggett wrote:
> Ian Holsman wrote:
> 
> > just wondering what people's position is on this one.
> > 
> > should we be masking error pages coming from the reverse proxy
> > with the 'standard' server responses from the main server.
> > 
> > we really need to do something when we are using mod-include to
> include
> > a reverse proxied subcomponent.
> > at the moment it will show the 404 page from the r-proxy server.
> > if we try to include a normal file, we get the SSI error message
> > '[error]'.
> > 
> > I'm proposing that proxy-http does the same thing, and mask the
> > errorpages returned from the appserver
> 
> MSIE has this behavior - and it's bogus. A replacement 404 page could
> mask the real content that is returned that could be more useful.
> 
> I have seen some people ask for this behavior though and yes, in some
> cases it can be useful - at best it should be possible to enable 404
> replacement with a config directive, but it definitely shouldn't be the
> default.

The other problem I'm seeing at the moment is when the page being
requested is a r-proxy.

<html>
<!--#include virtual="/pma/404.html"-->
</html>

IF /pma/404.html is handled by the default handler (and is missing)
I get the standard "[an error occured...]"

IF the /pma/ is proxypassed it shows the 404 page of the other server.
This behavior is should NOT be the default behavior, it should be the
"[an error occured]".

Oh..
does anyone have any objections to the following patch.
it just passes the error code of the proxied request instead of 
passing a '200' all the time. 

I think this should be fixed regardless.


Index: proxy_http.c
===================================================================
RCS file: /home/cvs/httpd-proxy/module-2.0/proxy_http.c,v
retrieving revision 1.94
diff -u -u -r1.94 proxy_http.c
--- proxy_http.c	2001/08/30 19:48:02	1.94
+++ proxy_http.c	2001/09/18 20:39:24
@@ -850,7 +850,7 @@
                          "proxy: header only");
         }
     }
-    return OK;
+    return r->status;
 }
 
 static
@@ -954,6 +954,7 @@
     status = ap_proxy_http_process_response(p, r, p_conn, origin,
backend, conf,
                                             bb, server_portstr);
     if ( status != OK ) {
+        ap_proxy_http_cleanup(r, p_conn, backend);
         return status;
     }

> 
> Regards,
> Graham
> -- 
> -----------------------------------------
> minfrin@sharp.fm		"There's a moon
> 					over Bourbon Street
> 						tonight..."
-- 
Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608


Re: handling 404's in reverse proxy.

Posted by Graham Leggett <mi...@sharp.fm>.
Ian Holsman wrote:

> just wondering what people's position is on this one.
> 
> should we be masking error pages coming from the reverse proxy
> with the 'standard' server responses from the main server.
> 
> we really need to do something when we are using mod-include to include
> a reverse proxied subcomponent.
> at the moment it will show the 404 page from the r-proxy server.
> if we try to include a normal file, we get the SSI error message
> '[error]'.
> 
> I'm proposing that proxy-http does the same thing, and mask the
> errorpages returned from the appserver

MSIE has this behavior - and it's bogus. A replacement 404 page could
mask the real content that is returned that could be more useful.

I have seen some people ask for this behavior though and yes, in some
cases it can be useful - at best it should be possible to enable 404
replacement with a config directive, but it definitely shouldn't be the
default.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: handling 404's in reverse proxy.

Posted by Gabriel Russell <g....@ieee.org>.
At 10:55 AM 9/18/2001 -0700, you wrote:
>just wondering what people's position is on this one.
>
>should we be masking error pages coming from the reverse proxy
>with the 'standard' server responses from the main server.
>
>we really need to do something when we are using mod-include to include
>a reverse proxied subcomponent.
>at the moment it will show the 404 page from the r-proxy server.
>if we try to include a normal file, we get the SSI error message
>'[error]'.
>
>I'm proposing that proxy-http does the same thing, and mask the
>errorpages returned from the appserver

I propose that several (any?) error be handled in a customizable way. It 
may be nice to show the raw error, it may be nice to show a nice error 
page, it may be nice to try to get the page from the next IP address 
returned by the DNS lookup.


>--
>Ian Holsman          IanH@cnet.com
>Performance Measurement & Analysis
>CNET Networks   -   (415) 364-8608