- From: Brian Smith <brian@briansmith.org>
- Date: Tue, 18 Mar 2008 09:18:00 -0700
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Stefan Eissing'" <stefan.eissing@greenbytes.de>
- Cc: "'Mark Nottingham'" <mnot@mnot.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Julian Reschke wrote: > here's what I'd like to do, based on Mark's summary and > Stefan's latest > proposal: > > In the description of the Allow header, replace > > This field cannot prevent a client from trying other methods. > However, the indications given by the Allow header field value > SHOULD be followed. The actual set of allowed methods is defined > by the origin server at the time of each request. > > by > > This field cannot prevent a client from trying other methods. > The published set of allowed methods is defined by the > origin server at the time of each request. The absence of > methods in this set has no defined semantics. The first sentence "This field cannot prevent..." is meaningless and thus confusing. The server cannot prevent the client from doing anything. It should be removed. "The absense of of methods in this set has no defined semantics" implies that the presence of methods in the set does have (well-)defined semantics, which is not really true. How about: "The methods listed in the Allow field of a response were allowed when that response was produced; additional, unlisted, methods may have been allowed at that time as well. Regardless of whether or not a method was listed in a previously-returned Allow field, the server MAY allow or refuse the use of any method in any (future) request. Servers are RECOMMENDED to include an accurate and complete set of methods in any Allow field returned in a response." - Brian
Received on Tuesday, 18 March 2008 16:18:33 UTC