> -----Ursprüngliche Nachricht-----
> Von: Jiri Tulach - Position
> Gesendet: Freitag, 14. Dezember 2007 08:39
> An: dev@httpd.apache.org
> Betreff: Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR
> 
> 
> It's possible fault of mod_fastcgi which returns 
> HTTP_INTERNAL_SERVER_ERROR in cases when server is overloaded or 
> external fastcgi instances are unavailable. Unfortunately 
> mod_fastcgi is 
> not actively developed even thought lot of people use it in 
> production 
> sites.
> 
> But I still don't understand why proxy which has an option to 
> get proper 
> data from another (probably) working server stops trying to 
> failover. I 
> think from proxy point of view it doesn't matter why server is 
> unavailable. Or am I missing something?

1. HTTP_INTERNAL_SERVER_ERROR can be the result of an internal proxy problem.
   In this case it would be wrong failing over.

2. If HTTP_INTERNAL_SERVER_ERROR is returned it is possible that the backend
   processed at least parts of the request. And at least for non idempotent
   requests it would be entirely wrong to fail over.

So please fix mod_fastcgi to return the correct error code. This is NO bug
of the proxy.

Regards

Rüdiger

> 
> Thanx for comments.
> 
> Jiri Tulach
> 
> William A. Rowe, Jr. napsal(a):
> > Mladen Turk wrote:
> >> Jir wrote:
> >>>
> >>> is there any reason why HTTP_INTERNAL_SERVER_ERROR 
> returned by proxy 
> >>> handler cannot failover to another worker?
> >>
> >> Because HTTP_INTERNAL_SERVER_ERROR is used to represent either
> >> misconfiguration or even worse things like memory allocation
> >> failures. In essence non recoverable error.
> >> However, I'm not saying some scheme handler doesn't have
> >> bug returning HTTP_INTERNAL_SERVER_ERROR instead something
> >> else.
> >
> > Considering we have...
> >
> >   #define HTTP_BAD_GATEWAY                   502
> >   #define HTTP_SERVICE_UNAVAILABLE           503
> >   #define HTTP_GATEWAY_TIME_OUT              504
> >
> > it seems like most of the INTERNAL_SERVER_ERROR's should be 
> considered
> > for more explicit messages, eh?
> 

Reply via email to