<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">It would be interesting to amend the flawed RFC to adapt to the real world then, wouldn't it?<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br></div><div class="gmail_extra"><div style="font-size:small;color:rgb(51,51,153)" class="gmail_default">​It is indeed logic and useful as the answer length gets reduced​.<br></div><div style="font-size:small;color:rgb(51,51,153)" class="gmail_default">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.<br></div><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Fri, Aug 4, 2017 at 7:36 PM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Friday 04 August 2017 09:42:42 Frank Liu wrote:<br>
> Valentin,<br>
><br>
> I checked the trac and basically it says very complicated to properly<br>
> implement. When I try the same curl against <a href="http://apache.org" rel="noreferrer" target="_blank">apache.org</a>, they just return a<br>
> blank Allow header to compliant RFC. Maybe nginx can do the same?<br>
><br>
</span>[..]<br>
<br>
Why should nginx do the same?  Is there any real problem with that?<br>
<br>
According to RFC:<br>
<br>
 | An empty Allow field value indicates that the resource allows no methods,<br>
 | which might occur in a 405 response if the resource has been temporarily<br>
 | disabled by configuration.<br>
<br>
that, as you know, isn't the case for <a href="http://apache.org" rel="noreferrer" target="_blank">apache.org</a>.  So, such behavior can<br>
only mislead a client.<br>
<br>
Unfortunately, the real world sometimes a bit different than theory of<br>
RFC authors.  Strict and blind following to RFC is fine for academic<br>
purposes, but doesn't always work for real world applications.  It's<br>
definitely not the goal you should achieve by any price.<br>
<div class="HOEnZb"><div class="h5"><br>
  wbr, Valentin V. Bartenev<br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>