Anne van Kesteren wrote:
On Sun, 14 May 2006 13:59:34 +0200, Jim Ley <[EMAIL PROTECTED]> wrote:
There are currently some methods that can't be allowed for security
reasons and because such method smay be introduced in the future as
well allowing arbitrary method names does not seem like a good idea.
I think you need to list these methods that cannot be used for
security reasons, to explain more of the motivations for this
decision. It also appears to be a direct reversal of the decision at
the previous f2f (issue 74) It would be good to see what had changed
in between to motivate the change, as there was no public discussion,
other than more support for having any verb.
I'm just stating the resolutions as they have been made here. Feedback
from implementors suggested that TRACE and CONNECT have issues and that
future HTTP methods might become problematic (new specification
released, servers updated, UAs are not, hole). What was raised against
What kind of issues? Please be more specific.
Furthermore: if specifications update the definitions of methods in an
incompatible way, that's first of all the problem of these
specifications. The whole point in publishing specifications about new
HTTP methods is *not* to change them in incompatible ways once they are
deployed. If a standards body fails to adhere to that rule - their problem.
Don't cripple XHR because of that.
that is that it hurts adoption of new HTTP methods. That's true for all
other types of APIs as well though. Internet Explorer 7 as opposed to
What other types of APIs?
Internet Explorer 6 uses a whitelist and other browsers vendors are
planning to do the same thing. The whitelist would contain all "safe
methods" currently spreaded over various RFCs.
What specifically are you referring to when you say "safe"? I guess not
the thing defined in Section 9.1.1 of RFC2616
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>), right?
If IE7 - for instance - fails to support the ACL method (see RFC3744) -
I would consider this a bug that hopefully will get fixed before it gets
released.
Mark Nottingham would report back if the IETF was ok with this approach
or not.
In my opinion, forbidding implementations to allow arbitrary HTTP
methods is clearly the wrong thing to do.
(Speaking as active member of the IETF WebDAV working group, and as
author or co-author of several WebDAV related RFCs - most of which
defining new HTTP methods)
Best regards, Julian
