- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 12 May 2008 23:07:49 +0200
- To: "Sunava Dutta" <sunavad@windows.microsoft.com>
- Cc: "public-webapi@w3.org" <public-webapi@w3.org>, "Gideon Cohn" <gidco@windows.microsoft.com>, "Ahmed Kamel" <Ahmed.Kamel@microsoft.com>, "Zhenbin Xu" <zhenbinx@windows.microsoft.com>, "Doug Stamper" <dstamper@exchange.microsoft.com>
On Mon, 12 May 2008 22:27:05 +0200, Sunava Dutta <sunavad@windows.microsoft.com> wrote: >> > 1. Mentioning for each header the reasons for restriction. (I >> > think security is paramount but for shipped implementations I would >> > hesitate to reduce surface area of attack unless there is a compelling >> > reason. It's much harder to restrict once we ship!) >> >> The restrictions on allowed headers have come forth based on >> implementation feedback from Opera, Apple, and Mozilla. If you have >> feedback that suggests the list of headers should be different, please >> let us know. > > [Sunava Dutta] Ah, sorry I'm not being clear. What I'm asking for is the > reasons for why the headers are blocked (based on implementation > feedback, but what is the feedback per blocked header?) to be called out > for each header in the spec. Otherwise it seems arbitrary. I see. (Your original message seemed to imply the list was not correct.) To be honest, and as I've stated in my reply to Julian, I'm not sure what the rationale is for some of them. Hopefully implementors can chime in on this thread and provide feedback for why each of the headers listed in setRequestHeader() is blocked. I'm not sure if that information should be included in the specification itself though. Generally that's not done in specifications as far as I can tell. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Monday, 12 May 2008 21:08:31 UTC