HTTP/405

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

HTTP/405

Frank Liu
https://tools.ietf.org/html/rfc7231#page-59 says:

... The origin server MUST generate an
   Allow header field in a 405 response containing a list of the target
   resource's currently supported methods.

nginx doesn't seem to have Allow header field. Is that against RFC?

curl -v -X TRACE http://nginx.org
* Rebuilt URL to: http://nginx.org/
*   Trying 95.211.80.227...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 80 (#0)
> TRACE / HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.54.0
> Accept: */*
< HTTP/1.1 405 Not Allowed
< Server: nginx/1.13.3
< Date: Fri, 04 Aug 2017 05:25:26 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 173
< Connection: close
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.13.3</center>
</body>
</html>
* Closing connection 0

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

nginx mailing list
How was that 405 generated?
Show used configuration please.
---
B. R.

On Fri, Aug 4, 2017 at 7:28 AM, Frank Liu <[hidden email]> wrote:
https://tools.ietf.org/html/rfc7231#page-59 says:

... The origin server MUST generate an
   Allow header field in a 405 response containing a list of the target
   resource's currently supported methods.

nginx doesn't seem to have Allow header field. Is that against RFC?

curl -v -X TRACE http://nginx.org
* Rebuilt URL to: http://nginx.org/
*   Trying 95.211.80.227...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 80 (#0)
> TRACE / HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.54.0
> Accept: */*
< HTTP/1.1 405 Not Allowed
< Server: nginx/1.13.3
< Date: Fri, 04 Aug 2017 05:25:26 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 173
< Connection: close
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.13.3</center>
</body>
</html>
* Closing connection 0

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

Valentin V. Bartenev-3
In reply to this post by Frank Liu
On Thursday 03 August 2017 22:28:41 Frank Liu wrote:
> https://tools.ietf.org/html/rfc7231#page-59 says:
>
> ... The origin server MUST generate an
>    Allow header field in a 405 response containing a list of the target
>    resource's currently supported methods.
>
> nginx doesn't seem to have Allow header field. Is that against RFC?
>

Please, look at the explanations in https://trac.nginx.org/nginx/ticket/1161

  wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

Frank Liu
In reply to this post by nginx mailing list
B.R.
If you read my original post carefully, you will see the test was against http://nginx.org and I certainly don't have their configuration, but you can run the same curl test against your own nginx server and get the same result.

On Fri, Aug 4, 2017 at 3:46 AM, B.R. via nginx <[hidden email]> wrote:
How was that 405 generated?
Show used configuration please.
---
B. R.

On Fri, Aug 4, 2017 at 7:28 AM, Frank Liu <[hidden email]> wrote:
https://tools.ietf.org/html/rfc7231#page-59 says:

... The origin server MUST generate an
   Allow header field in a 405 response containing a list of the target
   resource's currently supported methods.

nginx doesn't seem to have Allow header field. Is that against RFC?

curl -v -X TRACE http://nginx.org
* Rebuilt URL to: http://nginx.org/
*   Trying 95.211.80.227...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 80 (#0)
> TRACE / HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.54.0
> Accept: */*
< HTTP/1.1 405 Not Allowed
< Server: nginx/1.13.3
< Date: Fri, 04 Aug 2017 05:25:26 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 173
< Connection: close
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.13.3</center>
</body>
</html>
* Closing connection 0

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

Frank Liu
In reply to this post by Valentin V. Bartenev-3
Valentin,

I checked the trac and basically it says very complicated to properly implement. When I try the same curl against apache.org, they just return a blank Allow header to compliant RFC. Maybe nginx can do the same?

curl -v -X TRACE http://apache.org

* Rebuilt URL to: http://apache.org/

*   Trying 140.211.11.105...

* TCP_NODELAY set

* Connected to apache.org (140.211.11.105) port 80 (#0)

> TRACE / HTTP/1.1

> Host: apache.org

> User-Agent: curl/7.54.0

> Accept: */*

< HTTP/1.1 405 Method Not Allowed

< Date: Fri, 04 Aug 2017 16:38:42 GMT

< Server: Apache/2.4.7 (Ubuntu)

< Allow: 

< Content-Length: 223

< Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>405 Method Not Allowed</title>

</head><body>

<h1>Method Not Allowed</h1>

<p>The requested method TRACE is not allowed for the URL /.</p>

</body></html>

* Connection #0 to host apache.org left intact



On Fri, Aug 4, 2017 at 4:05 AM, Valentin V. Bartenev <[hidden email]> wrote:
On Thursday 03 August 2017 22:28:41 Frank Liu wrote:
> https://tools.ietf.org/html/rfc7231#page-59 says:
>
> ... The origin server MUST generate an
>    Allow header field in a 405 response containing a list of the target
>    resource's currently supported methods.
>
> nginx doesn't seem to have Allow header field. Is that against RFC?
>

Please, look at the explanations in https://trac.nginx.org/nginx/ticket/1161

  wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

Valentin V. Bartenev-3
On Friday 04 August 2017 09:42:42 Frank Liu wrote:
> Valentin,
>
> I checked the trac and basically it says very complicated to properly
> implement. When I try the same curl against apache.org, they just return a
> blank Allow header to compliant RFC. Maybe nginx can do the same?
>
[..]

Why should nginx do the same?  Is there any real problem with that?

According to RFC:

 | An empty Allow field value indicates that the resource allows no methods,
 | which might occur in a 405 response if the resource has been temporarily
 | disabled by configuration.

that, as you know, isn't the case for apache.org.  So, such behavior can
only mislead a client.

Unfortunately, the real world sometimes a bit different than theory of
RFC authors.  Strict and blind following to RFC is fine for academic
purposes, but doesn't always work for real world applications.  It's
definitely not the goal you should achieve by any price.

  wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

nginx mailing list
It would be interesting to amend the flawed RFC to adapt to the real world then, wouldn't it?

Much like in any languages, specifications/reference and real world offen differ, but that should me a pretext to ignor the specs are here for a reason: make everyone try to speak the same language and be accessible to everyone else.

From what I understand, the fix would be the following: the RFC should accept an empty Allow and consider it equivalent to its presence with an empty value.
​It is indeed logic and useful as the answer length gets reduced​.
However, one might wonder about backwards-compatibility, as current-day non-compliant Web servers which do not specify the Allow header might be interpreted by future clients as having no available method to gather the requested URI, even if that was not the initial goal.
---
B. R.

On Fri, Aug 4, 2017 at 7:36 PM, Valentin V. Bartenev <[hidden email]> wrote:
On Friday 04 August 2017 09:42:42 Frank Liu wrote:
> Valentin,
>
> I checked the trac and basically it says very complicated to properly
> implement. When I try the same curl against apache.org, they just return a
> blank Allow header to compliant RFC. Maybe nginx can do the same?
>
[..]

Why should nginx do the same?  Is there any real problem with that?

According to RFC:

 | An empty Allow field value indicates that the resource allows no methods,
 | which might occur in a 405 response if the resource has been temporarily
 | disabled by configuration.

that, as you know, isn't the case for apache.org.  So, such behavior can
only mislead a client.

Unfortunately, the real world sometimes a bit different than theory of
RFC authors.  Strict and blind following to RFC is fine for academic
purposes, but doesn't always work for real world applications.  It's
definitely not the goal you should achieve by any price.

  wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/405

Valentin V. Bartenev-3
On Monday 07 August 2017 19:21:52 B.R. via nginx wrote:

> It would be interesting to amend the flawed RFC to adapt to the real world
> then, wouldn't it?
>
> Much like in any languages, specifications/reference and real world offen
> differ, but that should me a pretext to ignor the specs are here for a
> reason: make everyone try to speak the same language and be accessible to
> everyone else.
>
> From what I understand, the fix would be the following: the RFC should
> accept an empty Allow and consider it equivalent to its presence with an
> empty value.
[..]

The fix for RFC would be to allow 405 without "Allow" header.

  wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Loading...