#2564 closed defect (invalid)
nginx returns 501 when 400 is expected
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | nginx-1.26 |
| Component: | nginx-core | Version: | 1.25.x |
| Keywords: | Cc: | bjorn248@… | |
| uname -a: | Linux 5c6ed1f9df74 6.4.16-linuxkit #1 SMP PREEMPT_DYNAMIC Wed Oct 25 15:08:07 UTC 2023 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.25.3
built by gcc 12.2.0 (Debian 12.2.0-14) built with OpenSSL 3.0.9 30 May 2023 (running with OpenSSL 3.0.11 19 Sep 2023) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -ffile-prefix-map=/data/builder/debuild/nginx-1.25.3/debian/debuild-base/nginx-1.25.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' |
||
Description
nginx seems to be exhibiting unexpected behavior when sending an invalid value for the Transfer-Encoding header.
I've been using the nginx docker container to test with locally:
docker run -p 8080:80 nginx
The following curl request results in an HTTP 501:
curl -I -X POST -H "Transfer-Encoding: invalid" localhost:8080
According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding there are only 4 valid values for the Transfer-Encoding header. If a client sends an invalid value, I'd expect the server to respond with an HTTP 400. nginx responds with an HTTP 501.
Change History (3)
comment:1 by , 5 months ago
comment:2 by , 5 months ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
There can be other transfer encodings, for example, registered by newer RFCs, see here. As such, as long as the request is syntactically correct, but the server doesn't recognize the particular transfer encoding being used, it is expected to respond with 501 (Not Implemented), and not 400 (Bad Request).
Ah, never mind, this is the behavior specified by the RFC. "A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented)."
Definitely not intuitive behavior in the RFC.