- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 12 Feb 2008 21:51:21 -0800
- To: "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Henrik Nordström <henrik@henriknordstrom.net>
Mark, Roy, any thoughts? I'm inclined to go with SHOULD unless someone objects... On 06/02/2008, at 10:51 AM, Henrik Nordström wrote: > SHOULD. If the server can determine the valid list of methods it > SHOULD > indicate this with Allow. This mechanism is used for enabling HTTP > extensions in the client such as WebDAV, CalDAV etc and a MAY level > requirement is too weak for this purpose as the client should not be > expected to guess that these features is available even if it MAY. > > MAY level requirements is for optional features or alternative ways of > doing things, not things which should be done if you can. > > SHOULD is for things which you should do, but where things will quite > likely cope even if you don't. I.e. sending the Allow header where not > sending the Allow header which in worst case makes clients capable of > using extensions not enabling these extensions. > > tis 2008-02-05 klockan 08:51 -0800 skrev Mark Nottingham: >> Fair enough. Henrik, any thoughts about SHOULD vs MAY? Roy and Mark >> both expressed a preference for MAY. >> >> >> On 05/02/2008, at 7:35 AM, Henrik Nordström wrote: >> >>> I meant replacing MUST by SHOULD, making the use of Allow in 405 >>> responses a SHOULD level requirement. >>> >>> This is a requirement that is in some cases impractical for >>> servers to >>> implement properly. And it's also a case where it's most likely >>> better >>> the sever doesn't say anything at all if it doesn't know than to try >>> to >>> guess.. If it doesn't know let the client guess if it want. >>> >>> But on the other hand a 405 without Allow is pretty much equivalent >>> to a >>> 403. So an alternative approach would be to add a note that if the >>> server can not provide a reliable list of allowed methods then 403 >>> should be returned instead of 405, reserving 405 to be used only >>> when >>> the server knows within rasonable doubt what methods it accepts on >>> the >>> resource. And this is probably a better way to address the problem. >>> >>> I do not think relaxing the meaning of Allow is a good idea. If >>> Allow is >>> given then the client SHOULD assume it's the truth. Changing this >>> would >>> render Allow as such pretty useless. >>> >>> It's the same for Allow headers in response to GET btw. If the >>> server >>> doesn't really know then there SHOULD NOT be an Allow header in the >>> response. >>> >>> Regards >>> Henrik >>> >>> >>> >>> tis 2008-02-05 klockan 06:39 -0800 skrev Mark Nottingham: >>>> Are you saying that s/MUST/SHOULD/ is adequate, or agreeing that >>>> splitting it into two requirements, making the second a SHOULD, is >>>> necessary? >>>> >>>> >>>> On 05/02/2008, at 4:47 AM, Henrik Nordström wrote: >>>> >>>>> >>>>> mån 2008-02-04 klockan 23:08 -0800 skrev Mark Nottingham: >>>>>> My thinking was that it may be necessary to preserve the MUST on >>>>>> the >>>>>> presence of the header (in case any software had been written to >>>>>> depend upon its presence), but to loosen the implied requirement >>>>>> that >>>>>> the list of headers be complete. >>>>> >>>>> SHOULD is more than sufficuent for a such requirement level. >>>>> >>>>> Regards >>>>> Henrik >>>> >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 13 February 2008 05:51:32 UTC