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

Re: i24: Requiring Allow in 405 responses

From: Robert Sayre <rsayre@mozilla.com>
Date: Wed, 13 Feb 2008 01:22:44 -0500
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: <73AE5E91-725E-4B09-8715-CFCBF684DD43@mozilla.com>
To: Mark Nottingham <mnot@mnot.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 GMT

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