Re: i24: Requiring Allow in 405 responses

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/

Received on Wednesday, 13 February 2008 06:27:35 UTC