- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Sat, 10 Jun 2006 12:07:56 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
A whitelist seems very poor for interoperability and future work. E.g. I've been talking recently about the need for HTTP clients sometimes to be able to request a login challenge, a request which might involve a new method. The calendar access stuff in front of the IESG shortly, involves one new method. OSAF is working on a WebUI CalDAV client that would usefully be able to use this new method as well as other non-2616 methods. I wouldn't think that either a whitelist or a blacklist is necessary, but perhaps I haven't thought enough about the problem. Can somebody provide a list of the methods which would be blacklisted, and why? E.g. can somebody expand on the security problem with CONNECT? - why is CONNECT always bad, aren't there cases where it's useful - why that security problem can't be dealt with through other client approaches (e.g. explaining that the client code for XHR MUST NOT use CONNECT in certain ways)? Thanks, Lisa On Jun 9, 2006, at 9:50 PM, Mark Baker wrote: > > Folks, > > The W3C WebAPIs WG is attempting to standardize the XMLHttpRequest > Javascript object[1], and part of that work involves deciding how to > handle extension HTTP methods. > > Some of the WG is interested in establishing a "whitelist" of methods > deemed safe at the time of publication of our spec, with the intent > that all other methods would be disallowed. Others would prefer a > "blacklist", whereby we specify that methods known to be a security > problem (in the context of the use of XHR, e.g. CONNECT) not be used, > but that unknown methods be allowed. > > We would be interested to know what the HTTP community would > recommend. > > Thanks. > > [1] http://www.w3.org/TR/XMLHttpRequest/ > > Mark. >
Received on Saturday, 10 June 2006 19:08:16 UTC