Re: Extension HTTP methods

Actually, the action to check with ietf-http-wg was mine, which I'll do soon.

But +1 on Jim's position while I'm here. 8-)

Mark.
Mark Baker
Manager, Standards
Standards and Architecture
Mobile: +1.613.301.5470

----- Original Message -----
From: public-webapi-request@w3.org <public-webapi-request@w3.org>
To: Jim Ley <jim@jibbering.com>
Cc: Web APIs WG (public) <public-webapi@w3.org>
Sent: Sun May 14 08:19:53 2006
Subject: Re: Extension HTTP methods


On Sun, 14 May 2006 13:59:34 +0200, Jim Ley <jim@jibbering.com> wrote:
>> There are currently some methods that can't be allowed for security  
>> reasons and because such method smay be introduced in the future as  
>> well allowing arbitrary method names does not seem like a good idea.
>
> I think you need to list these methods that cannot be used for security  
> reasons, to explain more of the motivations for this decision.  It also  
> appears to be a direct reversal of the decision at the previous f2f  
> (issue 74)  It would be good to see what had changed in between to  
> motivate the change, as there was no public discussion, other than more  
> support for having any verb.

I'm just stating the resolutions as they have been made here. Feedback  
 from implementors suggested that TRACE and CONNECT have issues and that  
future HTTP methods might become problematic (new specification released,  
servers updated, UAs are not, hole). What was raised against that is that  
it hurts adoption of new HTTP methods. That's true for all other types of  
APIs as well though. Internet Explorer 7 as opposed to Internet Explorer 6  
uses a whitelist and other browsers vendors are planning to do the same  
thing. The whitelist would contain all "safe methods" currently spreaded  
over various RFCs.

Mark Nottingham would report back if the IETF was ok with this approach or  
not.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>






---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 15 May 2006 12:27:52 UTC