www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: handling 404's in reverse proxy.
Date Wed, 19 Sep 2001 21:34:49 GMT
On Wed, 2001-09-19 at 12:38, Chuck Murcko wrote:
> +1 for a start. Graham's suggestion of customized returned page with 
> this as default behavior looks great in the longer term.
> 
I was testing this out.
problem is.. if you return the error code for a virutal included file
you get the 404 error page and the [an error occured]
so I think I'll make the patch only 'on' if someone enables it

ProxyOverrideReturnedErrors
(which would default to what is the current behavior if not set)
> 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/
-- 
Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608


Mime
View raw message