- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 08 Jun 2006 09:11:33 +0200
- 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 UTC