Opened 9 months ago

Last modified 9 months ago

#1230 new enhancement

proxy_next_upstream: Add a config to add other errors

Reported by: stackoverflow.com/users/1100117/higuita Owned by:
Priority: minor Milestone:
Component: other Version: 1.10.x
Keywords: Cc:
Sensitive: no
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 Changed 9 months ago by mdounin

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.

comment:2 Changed 9 months ago by stackoverflow.com/users/1100117/higuita

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 Changed 9 months ago by mdounin

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 Changed 9 months ago by stackoverflow.com/users/1100117/higuita

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

Note: See TracTickets for help on using tickets.