W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i24: Requiring Allow in 405 responses

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 12 Feb 2008 22:28:26 -0800
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>
Message-Id: <2BECD38F-5210-4212-8064-D04D8EF52349@mnot.net>
To: Robert Sayre <rsayre@mozilla.com>

BTW, this is why I don't like linking conditional/unconditional  
compliance to SHOULD/MUST; it overloads 2119.


On 12/02/2008, at 10:26 PM, Mark Nottingham wrote:

>
>
> RFC2119;
>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that  
>> there may exist valid reasons in particular circumstances to ignore  
>> a particular item, but the full implications must be understood and  
>> carefully weighed before choosing a different course.
>
>
> On 12/02/2008, at 10:22 PM, Robert Sayre wrote:
>
>> 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/
>>>
>>>
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 13 February 2008 06:29:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT