W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] Review

From: Tyler Close <tyler.close@gmail.com>
Date: Mon, 8 Jun 2009 11:26:32 -0700
Message-ID: <5691356f0906081126q319f507aobf0caaf07e5ecddf@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: public-webapps@w3.org
On Fri, May 29, 2009 at 12:27 AM, Mark Nottingham<mnot@mnot.net> wrote:
> *** Substantial issues
> * POST as a "simple" method - POST is listed as a simple method (i.e., one
> not requiring pre-flight) because there are already security issues that
> allow an HTML browser to send cross-site POST requests. However, other
> contexts of use may not have this problem, and future developments may close
> that hole. Requiring a pre-flight for POST because it is unsafe is the right
> thing to do for both of these reasons.


> * Chattiness - The protocol set out here requires a pre-flight request every
> time a new URL is used; this will force Web sites to tunnel requests for
> different resources over the same URL for performance/efficiency reasons,
> and as such is not in tune with the Web architecture. A much more scalable
> approach would be to define a "map" of the Web site/origin to define what
> cross-site requests are allowed where (in the style of robots.txt et al; see
> also the work being done on host-meta, XRDS and similar). I made this
> comment on an older draft a long time ago, and have still not received a
> satisfactory response.

Using reasoning similar to your argument in "Chattiness", making POST
a non-"simple" method will force web sites to tunnel everything over
GET, as they commonly do today. So, I suspect your understandable
desire to make CORS somewhat compatible with web-arch will have the
opposite effect on deployed applications. We should be thankful that
HTML saved cross-site GET and POST from the overhead of CORS. I am.
With GET and POST to many URLs, it's possible to get most of the
benefits of the Web. It'd be a shame to lose POST in the name of
better web-arch and be left with only GET.

> However, other contexts of use may not have this problem...

Hopefully CORS will not be reused outside the web-browser. For
example, server-side code should not be subject to any of the
restrictions enforced by CORS. Hopefully, other contexts will model
themselves on the server-side, where there's no user ambient authority
associated with network requests.


"Waterken News: Capability security on the Web"
Received on Monday, 8 June 2009 18:27:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC