Brian Smith wrote: > 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. Agreed. > "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. I wouldn't go that far; the presence does have semantics, with some caveats. > 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." - This emphasizes a lot that the Allow set may change over time; in general I think this is misleading. It should only change when either the implementation or the "type" of the resource changes (for instance in WebDAV: collection vs non-collection) - "RECOMMENDED" re-adds the normative requirement that most people want to get rid of, as some servers do not get this right in practice (remember that RECOMMENDED == SHOULD). BR, JulianReceived on Tuesday, 18 March 2008 17:54:48 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 October 2011 12:14:00 GMT