- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 31 May 2006 18:59:54 +0200
- 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 UTC