On Mon, 15 May 2006 03:18:32 -0700, Julian Reschke <[EMAIL PROTECTED]>
wrote:
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.
They should indeed be mentioned and they are already blacklisted.
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?
It depends on what they do. The security guys might know of verbs that
kills...what do I know?
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?
If you are talking about specification writers I agree. If you speak for
applications developers, I think they could use a header for the verbs
instead. A simple proxy that tunnels the verbs should also work.
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?
I have reason to believe their behaviour is intentional and because of
security concerns, but I'm not totally sure. I know that the security
people here at Opera are against this behaviour and I suspect that the
Safari guys are also against this behaviour (since they do not support
arbitrary verbs).
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.
But it's already crippled today and not agreed upon! If you make design
based on the current behaviour you are making a big mistake.
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?
Right. This concern is valid and should be addressed in the spec. However,
I think that having this white-list is better than only GET, POST and PUT
(which I believe might be an alternative).
Cheers,
- Gorm Haug Eriksen
