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: Thu, 28 Feb 2008 17:15:11 +1100
Message-Id: <D4EE6232-FE28-4DA6-93B8-CEAEE9020284@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>

I don't feel like we're particularly making progress here (and I'm not  
trying to pick on Henrik in particular).

A number of dimensions have been talked about:

  1) Whether the list of headers MAY/SHOULD/MUST be present
     a) ... for 405 responses
     b) ... for OPTIONS responses
        I) ... that are generated by the origin server
        II) ... that are generated by intermediaries
  2) Whether the list of headers, in each of these cases, MAY/SHOULD/ 
MUST be complete

A few observations;

* (I) vs. (II) is IMO already taken care of; the text that mentions  
Allow in conjunction with OPTIONS starts "A 200 response SHOULD  
include..."
* There is no existing normative text for (b); OPTIONS lists Allow as  
an example, nothing more AFAICT. Expanding it to a SHOULD or MUST  
seems too aggressive, and software that depends upon it today is  
already taking liberties (unless a specific overlay protocol like  
WebDAV specifies otherwise).
* The spec is already crystal-clear about (a); it's a MUST.

That, in combination with the original issue description <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24 
 >, makes me believe that the best solution is to point out non- 
normatively in 14.7 Allow that the list doesn't have to contain all  
possible methods, since that kind of wiggle room is already --  
arguably -- implied. E.g., change

"The actual set of allowed methods is defined by the origin server at  
the time of each request."

to

"The actual set of allowed methods is defined by the origin server at  
the time of each request, and may not necessarily include all (or any)  
methods that the server would actually allow in a request if presented."

That's my proposal.


On 15/02/2008, at 9:09 PM, Henrik Nordström wrote:

> It's true that for the scope of the base HTTP/1.1 specifications Allow
> is completely useless.
>
> However, making it a MAY moves it out of the recommended set of
> implementation, forcing every extension who want to use it to  
> negotiate
> it's precense to upgrade the requirement to a SHOULD. Quite noticeably
> crippling the extension path of HTTP.
>
> If we were talking about OPTIONS *, then I would fully agree with the
> others that it's a MAY, but not GET or disallowed methods to a  
> specific
> resource. In most cases the server know pretty darn well what  
> methods it
> may handle on the resource.
>
> I see no reason why making the requirements for 405 substantially
> different than OPTIONS, just confuses implementers.
>
> If the desire is to make Allow a MAY in general then we may just as  
> well
> remove it entirely, moving it completely down to extension
> specifications, as it makes the feature completely useless from a
> specifications point of view as each extension then either MUST  
> upgrade
> the requirement to a SHOULD/MUST, or invent their own negotiation
> mechanism to announce the extension.
>
> Regards
> Henrik
>
>
>
>
> tis 2008-02-12 klockan 23:28 -0800 skrev Mark Nottingham:
>> Thoughts? I have three people who say they prefer MAY, and Robert is
>> starting to convince me...
>>
>>
>> Begin forwarded message:
>>
>>> Resent-From: ietf-http-wg@w3.org
>>> From: Robert Sayre <rsayre@mozilla.com>
>>> Date: 12 February 2008 11:11:58 PM
>>> To: Mark Nottingham <mnot@mnot.net>
>>> 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>
>>> Subject: Re: i24: Requiring Allow in 405 responses
>>> Archived-At: <http://www.w3.org/mid/AD1B6FC0-273F-44D6-B925-DE1C3C123101@mozilla.com
>>>>
>>>
>>>
>>>
>>> On Feb 13, 2008, at 1:26 AM, 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.
>>>
>>>
>>> Sure, let's contrast this text with what we have now.
>>>
>>> "You might help clients out if you send this, no one relies on it,
>>> most people don't bother."
>>>
>>> Does not sound like something that must be "carefully weighed". I
>>> claim that it doesn't matter a lick, unless you're writing a WebDAV
>>> server or something. By all means, opt in to the MAY in that case.
>>>
>>> - Rob
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>


--
Mark Nottingham     http://www.mnot.net/
Received on Thursday, 28 February 2008 06:15:25 GMT

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