Fwd: Extension methods & XMLHttpRequest

Discussion seems to have died down, and it's there for people to look
at for themselves, but I wanted to forward this response from Roy
Fielding (HTTP & URI editor), as there wasn't much push-back on it.

---------- Forwarded message ----------
From: Roy T. Fielding <fielding@gbiv.com>
Date: Jun 11, 2006 2:31 PM
Subject: Re: Extension methods & XMLHttpRequest
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>



On Jun 11, 2006, at 10:09 AM, Bjoern Hoehrmann wrote:
> You'll have to look at this from the user perspective. A browser
> that does not allow (for example) TRACE requests is less risky to
> use than one that does allow it. The question for browser vendors
> is then "Do we want to make a product that's more risky to use
> than competing products?"

That is absolutely absurd.  How about making a product that obeys
the relevant standards?

As I've stated numerous times on this list, the only reason there
is any concern about TRACE is because one company that "specializes
in security" used it as a marketing promotion to point out a
bug in an old version of MSIE.  There is no reason for browsers
to block TRACE.

What browsers need to do is obey the specs.  TRACE is not a problem.
If the browser sends already-non-secure cookies on a TRACE request,
then the response is going to contain those cookies.  So don't do that.
Don't whitelist methods -- whitelist the information the browser is
allowed to send in *any* request.  Allow the user to configure
the browser differently when new information is needed.

CONNECT is a protocol switch.  The only real risks for CONNECT are
for proxies that are tricked into connecting to the reserved ports
of older protocols.  For that reason, good systems limit CONNECT
requests to the well-known SSL-using ports and do not send things
like cookies in the CONNECT request.  Again, this should be configurable
by the user.

All HTTP methods fall into safe/unsafe categories.  It is absolutely
necessary that the browser distinguish between safe requests
(hyperlinks) and unsafe requests (a la buttons).  That is a browser
GUI issue and, for scripting, requires a user ack prior to sending the
unsafe request.  By default, all unknown methods should be considered
unsafe until the user configures otherwise.  There is no need for the
*protocols* to define whitelists when the developers can do so on
their own, based on their own applications, and according to their
own user needs.

....Roy

Received on Thursday, 15 June 2006 12:23:49 UTC