- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 19 Apr 2010 17:51:37 +0200
- 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