Opened 5 weeks ago

Last modified 4 weeks ago

#2032 new enhancement

Odd image_filter behavior on site behind HTTP authentication

Reported by: GarrettAlbright@… 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)

nginx-log.text (7.1 KB ) - added by GarrettAlbright@… 5 weeks ago.
Debug error log

Download all attachments as: .zip

Change History (2)

by GarrettAlbright@…, 5 weeks ago

Attachment: nginx-log.text added

Debug error log

comment:1 by Maxim Dounin, 4 weeks ago

Component: documentationnginx-module
Type: defectenhancement

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.

Note: See TracTickets for help on using tickets.