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

Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 19 Apr 2010 17:51:37 +0200
Message-ID: <4BCC7C09.3080508@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Maciej Stachowiak <mjs@apple.com>, Ben Laurie <benl@google.com>, Tyler Close <tyler.close@gmail.com>, Arthur Barstow <Art.Barstow@nokia.com>, ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On 19.04.2010 17:44, Jonas Sicking wrote:
> On Mon, Apr 19, 2010 at 1:11 AM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> On 19.04.2010 10:03, Maciej Stachowiak wrote:
>>> ...
>>>> I already did. If multiple layers blocked unknown response headers,
>>>> and each needed a separate way to opt them back in, we'd be in trouble.
>>> But that's not the case here. The blocking is solely at the API surface.
>>> No one is suggesting that proxies should block unknown response headers.
>>> ...
>> For the application, it's totally irrelevant who's blocking the header. If
>> it's blocked, it can't be used, and people *will* come up with ugly
>> workarounds which are likely to cause even more problems in the future.
> Unfortunately a blacklist approach is simply not safe enough. Fixing
> security problems as they come up is not good enough as the turnaround
> time is much too slow.

I'd like to see a detailed explanation for each of the headers in the 
IANA http reader registry why it's not allowed.

That should give us an insight about what the actual problem is (yes, I 
do see it for some headers), and then maybe give us some insight about 
how this translates to future headers.

Best regards, Julian
Received on Monday, 19 April 2010 15:52:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC