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 <vb...@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