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

Re: Extension HTTP methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 31 May 2006 18:59:54 +0200
Message-ID: <447DCB8A.1080500@gmx.de>
To: Mark Baker <distobj@acm.org>
CC: 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>

Mark Baker schrieb:
> 
> On 5/22/06, Mark Baker <distobj@acm.org> wrote:
>> I think that was ACTION-145 on Gorm.
> 
> Doh, I meant to paste this;
> 
> http://www.w3.org/2006/webapi/track/actions/145

Hi,

first of all, I checked current implementations, using the verbs GET 
(RFC2616), PROPFIND (RFC2518), REPORT (RFC3253) and FOOBAR (undefined).

Results:

Group A:

IE6 (MSXML): pass (all methods sent as-is)
Firefox 1.5: pass
Firefox 2.0 alpha (Bon Echo): pass

Group B:

IE7 beta2: passed PROPFIND, put rejects REPORT and FOOBAR with a runtime 
exception

Group C:

Safari: all (!) method names silently translated to GET
Opera 9 beta: same


As a developer both of codes and protocols, I absolutely prefer the 
behavior in Group A, because it allows *me* to decide when to use which 
extension point. Furthermore, it is what today ~9/10 of the currently 
deployed browsers allow. Don't break code that relies on it.

Regarding IE7beta2: that's bad, but at least script code will notice 
that something is wrong. Nevertheless, I have sent feedback to Microsoft 
(<https://connect.microsoft.com/feedback/ViewFeedback.aspx?SiteID=136&FeedbackID=83800>).

Finally, I don't think I need to say anything about Group C except: FIX IT!


Furthermore, I have looked at the F2F meeting minutes 
(<http://lists.w3.org/Archives/Public/public-webapi/2006May/att-0164/min-f-060501.html#item03>). 
I really don't grok the point of view that new methods would pose a 
security risk bigger than then one POST already is. POST may be 
anything, after all.

If future browsers by default do not allow "unknown" methods, protocol 
designers may be forced not to use new method names, or alternatively, 
to specify a way to tunnel those through POST. In which case the dreaded 
"insecure" method will be accessible through XHR, but as it is using 
POST there'll be no way to blacklist it later. So, essentially, using a 
white list will prevent new methods from being deployed, and thus will 
make it impossible to blacklist new methods that are *really* problematic.


Best regards, Julian
Received on Wednesday, 31 May 2006 17:00:03 GMT

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