Hello,
sorry, but I don't agree :(.
1. HTTP_INTERNAL_SERVER_ERROR can be the result of an internal proxy problem.
In this case it would be wrong failing over.
This means that current implementation mixes internal errors with errors on
back end. I suggest to consider implementing different error status handling to
distinguish what fails.
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.
and jean-frederic clere wrote:
The ajp proxy may have sent the request and get a partial response if
you fail over after HTTP_INTERNAL_SERVER_ERROR you may duplicate a
transaction.
I believe most of the users want correct response from the server instead of partial.
Also if server is in error state the partial response could be totally wrong or may
contain inappropriate informations. /?q=inappropriatelang=en_cz
If we talking about transactions how do you prevent user to don't repeat the
same request if he see that his previous request failed? Ok maybe there is not
user on other site but machine. So make this behavior configurable in cases
where you can ensure specific environment conditions.
So please fix mod_fastcgi to return the correct error code. This is
NO bug of the proxy.
a) I don't said there is a bug. I only asked why it is implemented in
that way.
b) I said mod_fastcgi is not in active development. There is almost no
support for this module and I'm not a developer of this module. But this
don't change the fact this is a popular module and widely used.
c) You have configuration option in proxy for bad formated headers
(ProxyBadHeader) so you probably assume not all back ends are correctly
implemented. Why don't have another option to ensure correct responses
from proxy?
Sorry guys but you still didn't convinced me why proxy should care about
one specific back end error - HTTP_INTERNAL_SERVER_ERROR. I rather think
there is a problem with mixing internal status errors and back end
errors mentioned in 1) above. But maybe I'm wrong.
Regards
Jiri Tulach
Plüm napsal(a):
-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?
