- From: Mark Baker <distobj@acm.org>
- Date: Mon, 12 Jun 2006 08:11:17 -0400
- To: "Hallvord R. M. Steen" <hallvord@opera.com>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Mark Nottingham" <mnot@yahoo-inc.com>, "Anne van Kesteren" <annevk@opera.com>, "Pete Kirkham" <mach.elf@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>
On 6/12/06, Hallvord R. M. Steen <hallvord@opera.com> wrote: > On Fri, 09 Jun 2006 13:21:00 +0200, Hallvord R. M. Steen > <hallvord@opera.com> wrote: > > >>>> Blindly standardising what one vendor does doesn't make sense; > >>> We can certainly assume they have thought long and hard about a > >>> change that WILL break existing content. > >> > >> It would be really great if we could work based on facts instead of > >> hearsay. > > > > Yes, but I can't quote people verbatim on a public mailing list without > > their permission. > > I will ask the MS developer and our senior HTTPS/networking dev if they > > can give me an explanation I can pass on, or even respond in this thread. > > > Here is the response: > > > The problem is that there's no way we can guarantee correct behavior for > new HTTP verbs whose semantics are not yet defined. For instance, should > a given method be idempotent? Are its results eligible to be cached? Etc. > > One of the security issues from allowing arbitrary verbs was reported a > few years ago. The "TRACE" verb can be used to circumvent the HTTPONLY > cookie directive. > http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf. While > the threat was overhyped (and can be fixed by disabling TRACE on the > server) the concern about permitting verbs with unknown > side-effects/combinatorial-effects remains. The method is immaterial in the single domain case, because the server can always deploy a resource which echos the input message via GET (or POST or ...), giving the script the cookies it wants. Mark.
Received on Monday, 12 June 2006 12:11:29 UTC