W3C home > Mailing lists > Public > public-webapi@w3.org > May 2006

Re: Extension HTTP methods

From: Jim Ley <jim@jibbering.com>
Date: Mon, 15 May 2006 10:16:15 +0100
Message-ID: <00c701c67800$381ff770$0302a8c0@Sniff>
To: "Web APIs WG \(public\)" <public-webapi@w3.org>

"Gorm Haug Eriksen" <gormer@opera.com>
>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.

And then creates a script on their webserver which sends a HOBBIT request 
back to them?  What scenarios is this HOBBIT method relevant other than in a 
Cross Site XHR environment?

> I have spoken  with some security people and they are concerned although 
> we in the group  see benefits in having arbitrary verbs.

That's fine, security people can pick a security policy for their UA, that 
shouldn't change that we in the specification allow any verb, just as we 
don't disallow arbitrary headers because someone might invent one that does 
something insecure.  Picking verbs is profiling HTTP, and I really think 
that's a bad idea, and the specification does not generally contain any 
security model, so why pick this one area to have one?

>I guess the problem is the vendors here.

There are lots of other incompatibilities with the spec, that hasn't so far 
led to us changing the spec, in fact the same f2f has relaxed the rules on 
being compatible with implementations.  Unfortunately that means pointing to 
the implementations and going that's what they do, that's what we'll spec. 
isn't so easy, so now you've opened us up to arguing 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.

It would be crippled - it may need to be crippled for security reasons, but 
I don't believe so, the HOBBIT scenario is not any more realistic than a 
HOBBIT header, or a HOBBIT magic GETable URL.  Using headers to signal is 
not RESTful, and very much not a solution.

>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.

I don't agree on a "whitelist" that everyone can agree on supporting, since 
if we put CHICKENS on a whitelist and a UA decides that is actually insecure 
and blocks it, it should be free to do so, so the whitelist will give us 
nothing, simply SHOULD support any VERB, and you're free to block any you 
want for security reasons is a much more sensible policy than a non 
mandatory whitelist.


Received on Monday, 15 May 2006 09:16:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC