Opened 7 years ago
Closed 7 years ago
#1161 closed defect (wontfix)
POST to static file causes 405 but lacks Allow header
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | other | Version: | 1.11.x |
| Keywords: | Cc: | ||
| uname -a: | Linux 1750studios.com 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.11.5
built by gcc 4.9.2 (Debian 4.9.2-10) built with OpenSSL 1.0.1t 3 May 2016 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-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 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed' |
||
Description
When trying to access a static resource (a static file) with the HTTP POST method, nginx will return a 405 Method not Allowed error, as expected.
But as stated in RFC 2616 Section 10.4.6, the response must contain a Allow header:
The response MUST include an
Allow header containing a list of valid methods for the requested
resource.
This is lacking in the response from nginx:
HTTP/1.1 405 Not Allowed Connection: keep-alive Content-Length: 166 Content-Type: text/html Date: Mon, 19 Dec 2016 16:21:46 GMT Server: nginx
Change History (3)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
For my use case it is no problem, I just wanted to point out that nginx is not following the RFC here, which is important as some software might rely on correct behavior.
comment:3 by , 7 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Correct behaviour here is not something really possible except in some simple special cases, as the module which returns the error doesn't know if some other methods are supported and were previously handled by other modules and/or by a special configuration, or not.
We can try to implement something more or less close to correct behaviour by remembering methods theoretically allowed in various modules during request processing. But this approach looks overcomplicated, especially for a problem which is never observed in practice. Also, even correctly implemented, this won't produce correct results when some methods are specially handled in the configuration, e.g., using conditional constructs like if ($request_method = FOO) { ... }.
Or we can simply return Allow: GET HEAD from static module. But this certainly will produce incorrect results in many cases, confusing "some software". And also can cause problems with configurations which rely on redirection of 405 errors.
Overall, I don't think we should try to fix anything here, at least unless there are some real problems observed. It may be a good idea to fix the RFC wording instead.
Do you observe any real problems due to lack of the
Allowheader? That is - if theAllowheader of the response is actually used in your case? If yes, how it is expected to be used?