Anne van Kesteren wrote:
On Wed, 20 Feb 2008 15:15:39 +0100, Mark Baker <[EMAIL PROTECTED]> wrote:
Your premise seems to be that in the future, the community might rally
around and widely deploy, brain-dead extensions which attempt to
violate the fundamental semantics of HTTP, in this case the safety of
GET messages. IMO, that's not a realistic concern.
I'm not talking about communities, or braind-dead extensions. I'm
talking about the theoretical possibility that this might already be
deployed on some servers around the world (or something of equivalent
nature) and that therefore allowing such cross-domain GET requests with
custom headers introduces a new attack vector. And introducing a new
attack vector is something we should avoid, regardless of whether being
vulnerable to that attack vector relies on violating the fundamental
semantics of HTTP.
(Amazon already has a service that works entirely on HTTP GET:
http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/MakingRESTRequests.html
Now you don't need custom headers there, but it's not too much of a
stretch to assume that someone else has a service deployed that does.)
We already know there are lots and lots of servers out there that
basically treat GET and POST the same and thus lets you to perform
unsafe operations from GET requests. And cross-site GET requests are
already possible today.
So it's not hard to imagine that there are servers out there that also
perform dangerous actions when custom headers are set, especially given
that that *is* safe today!
As I've said before, the question really isn't "is this useful" but
rather "can we be reasonably sure that this is safe". So far I've not
seen anyone answer that question with anything but a no.
Sure, we can put anything in the spec and point to the HTTP spec and say
"servers really shouldn't be doing that". However any responsible
browser vendor (me included) is not going to be willing to implement a
feature with unknown security issues.
/ Jonas
