On Sun, 14 May 2006 23:48:46 -0700, Julian Reschke <[EMAIL PROTECTED]>
wrote:
Anne van Kesteren wrote:
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.
Hi Julian,
I don't think these two methods are allowed in any implementations today
so they shouldn't be in use. However, the biggest concern is that someone
has implemented a HOBBIT method that do something insecure. I have spoken
with some security people and they are concerned although we in the group
see benefits in having arbitrary verbs.
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.
I guess the problem is the vendors here. The specification will try to
minimize the problems with already deployed solutions, but I think a
couple of vendors was a bit quick. E.g. if you try IE7 today you will see
that they have changed their behaviour. FF probably followed IE6 and
allowed arbitrary verbs. Opera has never allowed it.
Don't cripple XHR because of that.
I don't think it will be to much crippled. It would still be possible to
use headers to signal. I think the specification should provide a method
on a method that would satisfy the use-case of inventing new verbs. E.g. a
namespace on verbs or a custom header to signal the verbs.
In my opinion, forbidding implementations to allow arbitrary HTTP
methods is clearly the wrong thing to do.
I don't think the idea is to forbid, but rather have a white-list that we
all can agree on supporting. This list should contain all the verbs widely
in use today.
(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)
The WebDAV methods will probably be on top of that list :) Also, the
current suggestion is only a suggestion that will need more public
comments and work. Hope this email clarify some of your concerns and
explains a little on the reasons behind this issue. Thanks!
Cheers,
- Gorm Haug Eriksen
