Welcome! Log In Create A New Profile

Advanced

HTTP/405

Posted by Frank Liu 
Frank Liu
HTTP/405
August 04, 2017 07:30AM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
B.R. via nginx
Re: HTTP/405
August 04, 2017 12:50PM
How was that 405 generated?
Show used configuration please.
---
*B. R.*

On Fri, Aug 4, 2017 at 7:28 AM, Frank Liu <gfrankliu@gmail.com> 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
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Valentin V. Bartenev
Re: HTTP/405
August 04, 2017 01:10PM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Frank Liu
Re: HTTP/405
August 04, 2017 06:50PM
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 <nginx@nginx.org> wrote:

> How was that 405 generated?
> Show used configuration please.
> ---
> *B. R.*
>
> On Fri, Aug 4, 2017 at 7:28 AM, Frank Liu <gfrankliu@gmail.com> 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
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Frank Liu
Re: HTTP/405
August 04, 2017 06:50PM
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 <vbart@nginx.com>
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
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Valentin V. Bartenev
Re: HTTP/405
August 04, 2017 07:40PM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
B.R. via nginx
Re: HTTP/405
August 07, 2017 07:30PM
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 <vbart@nginx.com>
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
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Valentin V. Bartenev
Re: HTTP/405
August 07, 2017 07:50PM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Sorry, only registered users may post in this forum.

Click here to login