Opened 8 years ago
Last modified 8 years ago
#1230 new enhancement
proxy_next_upstream: Add a config to add other errors
Reported by: | higuita | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | other | Version: | 1.10.x |
Keywords: | Cc: | ||
uname -a: | Linux jumiaG01 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.5-1~bpo8+1 (2016-09-30) x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.10.3
built with OpenSSL 1.0.2k 26 Jan 2017 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_secure_link_module --with-http_sub_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/headers-more-nginx-module --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-auth-pam --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-cache-purge --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-dav-ext-module --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-development-kit --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-echo --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/ngx-fancyindex --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nchan --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-lua --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-upload-progress --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/nginx-upstream-fair --add-dynamic-module=/build/nginx-4hGAP1/nginx-1.10.3/debian/modules/ngx_http_substitutions_filter_module |
Description
Hi
i need to set a proxy_next_upstream on errors "410 Gone", but nginx do not support it.
Please add the http_410 or even better, a way to add custom error codes to the proxy_next_upstream, this way you cover all future error codes and increase nginx flexibility
Change History (4)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
For static content, i return 410 instead of 404, so that the CDN cached the request
we are now migrating servers, so some resources will exist on one server, but not yet on another.
We want to deliver the requests to all backends, if the resource is missing on one backend, try another one until the max retries is reach
being limited to just a few errors can be troublesome, as we may not control the backend error codes or need different error codes for other reasons (like error_page)
Using error_page for this is a lot more complex and do not exactly as the proxy_next_upstream
comment:3 by , 8 years ago
Could you please clarify reasons why you use 410 instead of 404? The 410 is expected to indicate that the resource in question is no longer available, and won't be available. For the exact use case when a resource is not yet available on the server the 404 code should be used instead.
The usability of arbitrary error codes in proxy_next_upstream
is understood, but it somewhat contradicts current implementation. And, given that most common cases are already supported, and for other cases error_page
provides similar functionality, it is not clear it worth the effort.
comment:4 by , 8 years ago
My problem with the 404 is they are not cached in the CDN, so i get all the 404 back to the server over and over again. With 410, if they are really missing, the request will be cached in the CDN/client and do not bother me again until the cache expires.
It also allows me to see when the request was made to a missing static content (410) or to any other missing page (404). This allows me to manage then in different ways and apply different log analysis
Could you please clarify why you want
proxy_next_upstream
for 410? 410 doesn't seem to be something normally returned by upstream servers.For arbitrary errors consider using proxy_intercept_errors combined with the
error_page
directive, it allows to configure arbitrary retry logic on various errors.