- From: Monsur Hossain <monsur@gmail.com>
- Date: Wed, 21 Aug 2013 21:46:04 -0500
- To: Brad Hill <hillbrad@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKSyWQ=MyqWULd3dUJQzz=ObaeqPD7sygzDUZu5RFitVZ+Phfg@mail.gmail.com>
On Wed, Aug 21, 2013 at 10:42 AM, Brad Hill <hillbrad@gmail.com> wrote: > The security considerations section discusses that the difference between > simple and non-simple isn't defined by any internal logic, but by > consistency with what existing pre-CORS user agents could already do > cross-origin. > > If it was an existing capability of user agents that existing servers had > to be prepared for, it was a "simple" request. > That makes sense. I just wasn't sure under what pre-CORS circumstances an Accept, Accept-Language or Content-Language header could be set on cross-origin requests. > Any new cross-origin capabilities had to be gated behind a pre-flight > check so that CORS wouldn't be creating additional risk to deployed > servers. > > In the end, it looks somewhat arbitrary because it reflects the vagaries > of the evolution in the previous 15 years of the Web platform. > > > On Tue, Aug 20, 2013 at 10:12 PM, Monsur Hossain <monsur@gmail.com> wrote: > >> The latest CORS spec defines the simple headers as Accept, >> Accept-Language and Content-Language. However the spec doesn't provide any >> insight into why these particular headers are special. What is the >> motivation for defining these as simple headers? My initial assumption was >> that a preflight was required for any cross-origin request that couldn't be >> done before the CORS spec existed. But its not clear to me how an author >> could set these simple headers on cross-origin requests before CORS. >> >> Thanks, >> Monsur >> >> >
Received on Thursday, 22 August 2013 02:46:31 UTC