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

Re: HTTPbis and the Same Origin Policy

From: Tyler Close <tyler.close@gmail.com>
Date: Mon, 30 Nov 2009 17:11:07 -0800
Message-ID: <5691356f0911301711y76ed90d4s4f463eb05ea8b3e@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> wrote:
>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> Yes.  At the application layer.
>> Perhaps we're just talking past each other here. I'll try again...
>> When creating a new application layer API, the designers must take
>> into account the SOP protection expected by resources. Currently,
>> these expectations aren't documented anywhere. In the status-quo, the
>> application layer API is expected to magically know all the SOP
>> restrictions and then document how it enforces them. I'm just
>> suggesting that it would be a good thing to remove some of the magic
>> here by writing down the SOP restrictions, leaving the application API
>> with only the task of documenting its enforcement mechanism.
> I agree with everything you're saying, but you haven't explained why
> this documentation should be at the protocol layer instead of the
> application layer.

1. To document the constraints that all user agents must enforce. The
restrictions apply to all APIs in the entire application layer, not
just some application APIs. HTTP is the layer below the application
API, where constraints upon all user agents are specified.

2. To document the security model that server-side resources are
written to. A HTTP resource expects the SOP to apply regardless of the
API used to generate requests. A HTTP resource is not a <img>
resource, or a <link> resource, or a curl resource, just an HTTP
resource. A resource does not expect the security model to change
based on the API used to produce the request. In many cases, this
distinction is not even knowable based on the content of the HTTP

3. Although some parts of SOP also apply to other protocols, such as
ftp, other parts are specific to HTTP, such as: rules around request
headers, redirects, the distinctions between POST and PUT, etc.


"Waterken News: Capability security on the Web"
Received on Tuesday, 1 December 2009 01:11:47 UTC

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