On Sun, 14 May 2006 23:48:46 -0700, Julian Reschke <julian.reschke@gmx.de>
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