W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: HTTPbis and the Same Origin Policy

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 25 Nov 2009 13:54:12 -0800
Message-ID: <7789133a0911251354u3d77c30ke79bee68700d87d1@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Nov 25, 2009 at 1:34 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 1:25 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Whether one can send an HTTP PUT request to another origin depends on
>> which API is being used.  For the HTML Form element, the HTML
>> specification contains this requirement.  For the XMLHttpRequest API,
>> the XMLHttpRequest specification contains the requirement.
>> The essence of the same-origin policy is the "sameness" relation
>> (i.e., how to compute it on URLs), which is what's contained in that
>> draft.  The details of what actions are restricted to the "same"
>> origin are details best left to the application layer.
> My impression is that the undefined consensus understanding of the
> Same Origin Policy incorporates the rule that no API (not just a
> specific API, such as HTML form) can allow a cross-origin PUT, unless
> the target resource has somehow opted out of SOP protection.

I think you're confusing two things:

1) What is an origin?
2) What restrictions ought we to place on cross-origin interactions?

draft-abarth-origin answers question (1), and the answer to this
question has been quite stable for a while as an equivalence relation
on URL/URI/IRIs.  Humorously, the relation has been more stable than
the things it relates!

The answer to question (2) is much less stable and depends on a lot of
application layer issues.  For example, consider the HTML Canvas
Element.  HTML5 lets you draw an image from an arbitrary origin onto
the canvas, but drawing a cross-origin image changes the behavior of
the toDataURL API.

I don't think there's a way to spec the answer to (2) at the protocol
layer.  The restrictions are inherently application-dependent.

> This
> rule, and others like it, are the source of much of the complexity in
> CORS. These rules are not left to the application layer.

Indeed.  Security in the application layer is quite complex.  That's
what makes life interesting.  :)

Received on Wednesday, 25 November 2009 21:55:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC