Opened 12 years ago
Last modified 12 years ago
#221 new enhancement
Feature Request - X-Accel header to singal if another upstream server should be attempted or not
Reported by: | riddla riddla | Owned by: | somebody |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-module | Version: | 1.3.x |
Keywords: | upstream x-accel abort | Cc: | |
uname -a: | |||
nginx -V: | N/A |
Description
Imagine the following upstream block:
upstream name {
server 1.1.1.1;
server 2.2.2.2 backup;
}
At the same time, imagine proxy_next_upstream is set as follows:
proxy_next_upstream http_503
It would be VERY useful to have an X-Accel header that one could pass to nginx from a backend to signal if 'another' backend server (from the same upstream) should be attempted or not.
The reasoning for this is as follows:
We 'manually' return 503 codes whenever something like a database restart occurs. This is a great way to signal to search engines to 'please return, this condition is just temporary'. My understanding is that this is a fairly common practice and googlebot and bingbot both understand html 503 + retry-after.
So, database is temporarily down for restart (lets say a downtime of 1-3 seconds), we send back a 503. In this case, we DO want nginx to try another server in the upstream block, as the database will most likely be restarted, and the request can be fullfiled. It should be noted that our backup servers are proxied via haproxy. Which handles the "try connect -> failed? -> wait -> try again" situation quite well.
But there are situations when it would be VERY useful to signal to nginx 'nope, this is a serious issue... dont attempt another backend server'.
The above is just one example, but I think it makes a lot of sense to be able to stop attempting other servers via a header sent from the backend.
after some thought, for the situation we wanted this feature for... x-accel-redirect can be used. with some careful planning...
but generally speaking, this feature would be great...