W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CORS explained simply

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 20 Feb 2015 11:59:15 +0100
Message-ID: <CADnb78jONxG7NgSSGTvP=y6H0xtVvVShMZ2tqTMOLVN9NnOmwQ@mail.gmail.com>
To: "chaals@yandex-team.ru" <chaals@yandex-team.ru>
Cc: Brad Hill <hillbrad@gmail.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>, WebAppSec WG <public-webappsec@w3.org>
On Fri, Feb 20, 2015 at 11:45 AM, chaals@yandex-team.ru
<chaals@yandex-team.ru> wrote:
> Because I am still working to parse it into something I can explain in clear
> english to my colleagues. (2 minutes later: "a 'simple request' is one that
> effectively does not use CORS. The most obvious reason these exist is
> because there are browsers that didn't implement CORS, such as those shipped
> before the specification was finished. ).

Basically, before CORS there were various APIs that could be used to
fetch across origins:

  <link rel=stylesheet>

The combination of these APIs allows fetches with methods GET and POST
to arbitrary URLs. All of these APIs conceal to some extent the full
response. All of these APIs include credentials in the fetch.

CORS addresses two needs:

1) Reading the contents of a resource across origins (not possible so far)

2) Allowing more types of fetches (with other methods and headers) to
be made across origins.

Of those, 1) requires altering the response by including some header
that indicates sharing the body with the other origin is okay and 2)
requires a preflight.

The original CORS specification called fetches that did not require a
preflight "simple", but I have not carried that terminology over into
Fetch. It is somewhat confusing.

Received on Friday, 20 February 2015 10:59:39 UTC

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