- From: Robert Sayre <rsayre@mozilla.com>
- Date: Wed, 13 Feb 2008 01:22:44 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>, Henrik Nordström <henrik@henriknordstrom.net>
This is wrong, aiui. SHOULD is for things that will be harmful if not obeyed, but there may a possibility that your implementation knows better somehow. I prefer MAY. - Rob On Feb 13, 2008, at 12:51 AM, Mark Nottingham wrote: > > 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 06:23:44 UTC