Re: [cors] Unrestricted access

On Wed, Jul 14, 2010 at 5:25 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 12:02 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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?
>
> UMP Level One doesn't use pre-flight requests so doesn't have this
> complexity, but also doesn't enable arbitrary HTTP methods and
> headers. Instead, the plan was to have UMP Level Two introduce a
> well-known URL per host that could be consulted to turn on this
> functionality for all resources. Level One and Level Two are split
> since Level One is meant to cover only things that are currently
> deployed.

So has IE, or any other browser, indicated support for UMP Level Two?

/ Jonas

Received on Thursday, 15 July 2010 00:46:30 UTC