On 18 Jul 2012, at 05:47, Ian Hickson wrote:
> On Wed, 18 Jul 2012, Henry Story wrote:
>>
>> So my argument is that this restriction could be lifted since
>>
>> 1. GET is indempotent - and should not affect the resource fetched
>>
>> 2. If there is no authentication, then the JS Agent could m
On Wed, 18 Jul 2012, Henry Story wrote:
>
> So my argument is that this restriction could be lifted since
>
> 1. GET is indempotent - and should not affect the resource fetched
>
> 2. If there is no authentication, then the JS Agent could make the
> request via a CORS praxy of its choosing, a
As I understand, a browser receiving even an unauthenticated GET request on a
resource from a JavaScript Agent, will pass the result on to the JS Agent only
if the server adds the
Access-Control-Allow-Origin: http://hello-world.example
header to the response.
I could not quite find it sp
On 18.7.2012 1:05, Ian Hickson wrote:
And if you want it to be defined in JS file itself, I'll suggest "use
strict" approach:
file> ---
"Access-Control-Allow-Origin: *";
(function(){
"use strict";
var x = 5;
})();
-
On Wed, 18 Jul 2012, Bronislav Klu�~Mka wrote:
>
> Since script is loaded using HTTP, why not use already defined CORS headers on
> server side while serving those scripts?
CORS is the wrong semantic. It's not "origin A is allowed to read content
from origin B", it's "origin A is allowed to caus
On 17.7.2012 23:53, Ian Hickson wrote:
My plan is to make it so that cross-origin URLs start cross-origin
workers. The main unresolved question is how to do this in an
opt-in manner. The best idea I've come up with so far is having
scripts that want
I'm not going to debate this with you.
Yes, the items you are raising have some relationship to the kind of
work WebAppSec is
doing, but they are not in fact in scope for this WG. Please take it elsewhere.
-Ekr
On Tue, Jul 17, 2012 at 2:50 PM, Henry Story wrote:
>
> On 17 Jul 2012, at 23:16, E
On Tue, 6 Dec 2011, Jonas Sicking wrote:
> On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead
> wrote:
> > A new scenario just came to my attention that I thought I might
> > pose to the list. Given the current same-origin restrictions on
> > new Worker(), it is problematic for Worker usage by any JS
On 17 Jul 2012, at 23:16, Eric Rescorla wrote:
> This all seems out of scope for the work WebAppSec is chartered for.
All of it? Really?
Let me look at the charter of the working group. Areas of scope for this
working group include:
[[
Secure Mashups: Several mechanisms for secure resource sh
This all seems out of scope for the work WebAppSec is chartered for.
Henry, can you please raise this in another venue.
-Ekr
[As WG Chair]
On Tue, Jul 17, 2012 at 1:15 PM, Henry Story wrote:
>
> On 17 Jul 2012, at 21:32, Dirk Pranke wrote:
>
>> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story
>
On 17 Jul 2012, at 21:32, Dirk Pranke wrote:
> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story wrote:
>> Ok, I don't really have a browser to hack on. On the other hand a few of us
>> are working on building a CORS
>> proxy at the read-write-web community group to enable javascript linked data
>>
On Mon, Jul 16, 2012 at 11:22 PM, Henry Story wrote:
>
> On 17 Jul 2012, at 08:10, Adam Barth wrote:
>
>
>
> On Mon, Jul 16, 2012 at 11:01 PM, Henry Story
> wrote:
>>
>> I first posted this to public-webapps, and was then told the security
>> discussions were taking
>> place on public-webappsec,
On Wed, 11 Jul 2012 00:52:06 +0200, Ian Hickson wrote:
Exponential back-off isn't at all necessarily the right solution. In
particular, consider mobile devices, where network connectivity goes in
and out as the user moves. Most of the time, you want to be trying to
connect as soon as you have co
Hi All,
The comment deadline for the April 26 SSE LC [LC] ended May 17. Since
the LC was published, I noted 2 comments, 1 bug report (see below) and 5
ED updates (see below).
The comments are:
1. 17-Apr-2012; Odin Hørthe Omdal (Opera);
http://lists.w3.org/Archives/Public/public-webapps/2012
14 matches
Mail list logo
