- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Fri, 24 Jun 2005 09:41:57 -0600
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Thu, 2005-06-23 at 16:24 -0700, Roy T. Fielding wrote: > On Jun 23, 2005, at 4:04 PM, Alex Rousskov wrote: > > > > The MUST requirement does not say "a list of ALL valid methods", but > > perhaps that is implied. > > It is implied by the definition of the Allow header field Both wordings seem similar to me; neither seems to require that all methods must be listed. Moreover, the Allow definition says: "The actual set of allowed methods is defined by the origin server at the time of each request." which might imply to some that the list of methods in Allow is dynamic and not something a client can rely on. FWIW, I believe that interpretation is close to reality. > , which > serves no purpose whatsoever if it does not include all of the > methods supported by the resource. The usefulness would depend on the application, I think. I agree that in some cases it would be useless. On the other hand, any application that relies on Allow header from an "unknown" server to mean something is probably not very robust (not to say broken). > It is better to not send the > field rather than send an inaccurate field value. ... unless the client knows that the value is just a generally inaccurate hint. If we are to fix this, I would suggest two related changes: - make Allow optional - make it clear that Allow value is imprecise and the reported set of methods may be partial If you insist that Allow value must be precise, then the wording should be adjusted to reflect that: We would have to prohibit 501 "Not Implemented" responses for methods previously listed in Allow. Introducing this new requirement (and the associated state) in errata does not seem like a good/practical idea to me because the old servers would continue to send imprecise Allows. There would be no reliable way to know whether the reported Allow value obeys the new/fixed semantics. Alex.
Received on Friday, 24 June 2005 15:44:33 UTC