Opened 4 years ago
Last modified 4 years ago
#2032 new enhancement
Odd image_filter behavior on site behind HTTP authentication
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-module | Version: | 1.19.x |
| Keywords: | Cc: | ||
| uname -a: | Linux Venus 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.18.0 (Ubuntu)
built with OpenSSL 1.1.1f 31 Mar 2020 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-5J5hor/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --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-compat --with-pcre-jit --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_gzip_static_module --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_conn_module --without-http_memcached_module --without-http_referer_module --without-http_split_clients_module --without-http_userid_module --add-dynamic-module=/build/nginx-5J5hor/nginx-1.18.0/debian/modules/http-echo |
||
Description
I've got a client that has a test site behind HTTP authentication and I'm noticing some odd behavior with images which pass through image_filter. As best as I can tell, if the client does not send the authentication credentials with its request, core nginx properly sends a 401 page, but then image_filter tries to filter that page as if it were an image, fails, and returns a 415 response. I've attached the full output of a debug log on such a request, but I'll highlight the lines I find interesting here:
2020/08/22 17:55:41 [info] 324862#324862: *23621 no user/password was provided for basic authentication, client: 172.68.141.20, server: live-test.gamerguides.com, request: "GET /assets/guides/resize140x-/200/Bannerlord_Companion_Recruit_1.jpg HTTP/1.1", host: "live-test.gamerguides.com" 2020/08/22 17:55:41 [debug] 324862#324862: *23621 http finalize request: 401, "/assets/guides/resize140x-/200/Bannerlord_Companion_Recruit_1.jpg?" a:1, c:1 2020/08/22 17:55:41 [debug] 324862#324862: *23621 image filter 2020/08/22 17:55:41 [debug] 324862#324862: *23621 image filter: "<h" 2020/08/22 17:55:41 [debug] 324862#324862: *23621 http special response: 415, "/assets/guides/resize140x-/200/Bannerlord_Companion_Recruit_1.jpg?"
According to https://trac.nginx.org/nginx/browser/nginx/src/http/modules/ngx_http_image_filter_module.c#L434 , image_filter logs the first two characters of the upstream file. Sure looks like those two characters are the start of an HTML page explaining the 401 error. And since the 401 status don't get to my browser, it doesn't try to redo the request with credentials attached.
So I think what needs to be happening is that if the upstream response is not a 200, the original response continues to be sent to the client. Otherwise image_filter can try to process the response body.
Attachments (1)
Change History (2)
by , 4 years ago
| Attachment: | nginx-log.text added |
|---|
comment:1 by , 4 years ago
| Component: | documentation → nginx-module |
|---|---|
| Type: | defect → enhancement |
The image filter does not allow any responses except images (and 304 Not Modified responses). This is by design: it is expected to prevent anything but images from being returned, including any errors potentially returned by upstream servers.
The use case described looks valid though, we may want to somehow improve image filter to work better in such configurations. In particular, something like image_filter_types, similar to sub_filter_types and/or xslt_types might be the way to go.
Debug error log