W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

Re: Extension HTTP methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 08 Jun 2006 09:11:33 +0200
Message-ID: <4487CDA5.6020500@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Mark Nottingham <mnot@yahoo-inc.com>, "Web APIs WG (public)" <public-webapi@w3.org>

Ian Hickson schrieb:
 > On Wed, 7 Jun 2006, Mark Nottingham wrote:
 >> Blindly standardising what one vendor does doesn't make sense; do you
 >> know *why* they consider it a security feature?
 >>
 >> The reputed security problems with various HTTP methods have been
 >> brought up many times, but I have yet to see an explanation of how they
 >> actually cause a security issue greater than supporting POST does.
 >
 > Beyond curiosity, does it matter why? There's no point us publishing a
 > spec that contradicts Microsoft's implementation if Microsoft's
 > implementation is not going to change (which it isn't, if the reason for
 > it being the way it is is Security).

1) How do you know it's not going to change, unless we have Microsoft's 
statement about it (instead of hearsay)? There's a reason I opened a bug 
report 
(<https://connect.microsoft.com/feedback/ViewFeedback.aspx?SiteID=136&FeedbackID=83800
 >).

2) Even if it *should* be intentional, it's definitively buggy. There's 
no reason at all to reject for instance REPORT, but to allow GET (REPORT 
is safe and idempotent). Similarly, it's unclear to me why MKREDIRECTREF 
is a risk, while POST isn't.

Best regards, Julian
Received on Thursday, 8 June 2006 07:11:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT