Re: [cors] Review

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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Monday, 8 June 2009 18:27:05 UTC