- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 14 Jul 2010 12:02:55 -0700
- To: Tyler Close <tyler.close@gmail.com>
- Cc: Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, Jaka Jančar <jaka@kubje.org>
On Wed, Jul 14, 2010 at 10:39 AM, Tyler Close <tyler.close@gmail.com> wrote: > On Tue, Jul 13, 2010 at 8:12 AM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Tue, Jul 13, 2010 at 3:47 AM, Anne van Kesteren <annevk@opera.com> wrote: >>> On Tue, 13 Jul 2010 12:35:02 +0200, Jaka Jančar <jaka@kubje.org> wrote: >>>> >>>> What I'd like is a global (per-host) way to disable these limitations all >>>> at once, giving XHR unrestricted access to the host, just like native apps >>>> have it. >>> >>> It used to be a mostly "global" per-resource switch, but the security folks >>> at Mozilla thought that was too dangerous and we decided to go with the >>> granular approach they proposed. This happened during a meeting in the >>> summer of 2008 at Microsoft. I do not believe anything has changed meanwhile >>> so this will probably not happen. >> >> This does not match my recollection of our requirements. The most >> important requirements that we had was that it was possible to opt in >> on a very granular basis, and that it was possible to opt in without >> getting cookies. Also note that the latter wasn't possible before we >> requested it and so this users requirements would not have been >> fulfilled if it wasn't for the changes we requested. >> >> Anyhow if we want to reopen discussions about syntax for the various >> headers that cors uses, for example to allow '*' as value, then I'm ok >> with that. Though personally I'd prefer to just ship this thing as >> it's a long time coming. > > Unless IE is soon to indicate support for all of the extra CORS > headers, pre-flight requests and configuration caching, the decision > should be to drop these unsupported features from the specification > and come up with a solution that can achieve consensus among widely > deployed browsers. I thought that was the declared policy for HTML5. > As you know, I also think that is the right decision for many > technical and security reasons. > > Jaka's request is reasonable and what the WG is offering in response > is unreasonable. I expect many other web application developers will > have needs similar to Jaka's. Meeting those needs with a simple > solution is technically feasible. The politics seem to be much more > difficult. As far as I understand, UMP requires the exact same sever script, no? / Jonas
Received on Wednesday, 14 July 2010 19:09:01 UTC