Mark Baker schrieb:
On 5/22/06, Mark Baker <[EMAIL PROTECTED]> 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
