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 21:51:21 -0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Henrik Nordström <henrik@henriknordstrom.net>
Message-Id: <92757CC2-295A-4157-893D-C90E1750B6C8@mnot.net>
To: "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>

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 GMT

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