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  

On 06/02/2008, at 10:51 AM, Henrik Nordström wrote:

> SHOULD. If the server can determine the valid list of methods it  
> 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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC