HTTP/405

[B.R.]

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 at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170807/c7e42eee/attachment.html>