Gorm Haug Eriksen wrote:
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
If these are problematic, blacklist them.
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.
How can an arbitrary verb be more dangerous than POST?
Please consider that if arbitrary methods can not be used with XHR,
future specification may be forced to use POST instead. So by banning
methods you don't know, you will make it more likely that people use
POST in the future, which is the contrary of what you wanted to achieve
initially, right?
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.
Do we have any evidence that IE7's current behavior is intentional? Did
anybody raise a bug report yet?
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.
You would be crippling the ability of protocol designers to use new
methods, that is one well understood HTTP extension mechanism would be
closed.
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.
Again, this restricts what future specs can do then.
(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!
Well, would that white list contain MKREDIRECTREF, UPDATEREDIRECTREF,
BIND, UNBIND and REBIND today? Once browser ship with these white lists,
is there any update strategy?
Best regards, Julian
