> Because it's undesirable to prevent the browser from sending cookies on an
> request,
Why ? I can understand why you can't do it today - but why is this
undesirable even for new applications? Ad tracking ?
~devdatta
On 7 July 2010 16:11, Charlie Reis wrote:
>
>
> On Wed, Jul 7, 2010 at 4:04
hmm, I think I quoted the wrong part of your email. I wanted to ask
why would it be undesirable to make CORS GET requests cookie-less. It
seems the argument here is reduction of implementation work. Is this
the only one? Note that even AnonXmlHttpRequest intends to make GET
requests cookie-less.
R
subresources from partner sites, etc. Is there a proposal or discussion
> about this somewhere?
> In the mean time, the canvas tainting example in the spec seems difficult to
> achieve.
> Charlie
>
>
> On Wed, Jul 7, 2010 at 5:05 PM, Devdatta Akhawe
> wrote:
>>
>>
>
> 3. Text, which can be in a separate document, exists that explains the
> security considerations for this specification. This may be done in a
> generic manner as they are most likely applicable to various APIs. The
> working group will decide whether the text is of sufficient quality.
Where
Hi
The CORS specification in its current form seems to be very concerned
about increasing attack surface of benign servers (the preflight
request etc. concern). Seeing [1] I am concerned about the other case
- benign clients and malicious cross origin servers.
for the tl;dr crowd - my (possibly w
hi
> You mean you didn't mention that I drafted a much better one over two
> years ago?
>
Garrett : could you send a link to your ES4 draft/proposal ? My simple
google skills couldn't find it.
thanks
devdatta
> And you felt this API was worth mentioning?
>
> My criticism is spot-on and appropr
hi
Is the word 'hash' for fragment identifiers common? I personally
prefer the attribute being called 'fragment' or 'fragmentID' over
'hash' - its the standard afaik in all the RFCs.
regards
devdatta
On 19 September 2010 15:47, João Eiras wrote:
>
>> That would be different behavior than what L
>
> 1) There are now two methods for getting at the URL parameters. The
and none for setting them?
cheers
devdatta
> 2) The origin attribute is now readonly. Once I wired up the origin
> attribute to the actual definition of how to compute the origin of a
> URL, it became obvious that we don
or any webservice that likes to have lots of query parameters - Google
Search for example.
In general, why would you not want a robust way to make complicated
queries - those who are making simple queries and prefer simple one
liners can continue using it.
On 20 September 2010 23:42, Darin Fishe
fying multiple instances of the
> same parameter name. I like the easy of supplying a JSON object, but
> I'm not in love with the magical syntax. An alternative is to use two
> APIs, like we current have for reading the parameter values.
>
> Adam
>
>
> On Mon, Se
e parameter name. I like the easy of supplying a JSON object, but
>> I'm not in love with the magical syntax. An alternative is to use two
>> APIs, like we current have for reading the parameter values.
>>
>> Adam
>>
>>
>> On Mon, Sep 20, 2010 at 11
>
> Perhaps appendParameter("x", "a", "b", "c") ?
>
where appendParameter is the second API - separate from setParameter?
so appendParmeter("x',"a","b","c"); setParameter("x","a")
would result in ?x=a
and without the second function call it would be
?x=a&x=b&x=c
I am fine with this.
cheers
de
> 2) I've added two flavors of appendParameter. The first flavor takes
> a DOMString for a value and appends a single parameter. The second
> flavor takes an array of DOMStrings and appends one parameter for each
> array. This seemed better than using a variable number of arguments.
-1
I reall
> If you really don't want to care what happened before, either do a
> clearParameter every time first, or define your own setParameter that
> just clears then appends. Append/clear is a cleaner API design in
> general imo, precisely because you don't have to worry about colliding
> with previous
> Maybe the code from the downloaded package has to be run from a local origin
> like chrome://*.
Doesn't the same issue that Chris raised still exist? You need a unit
of isolation that says "only code signed with this public key runs in
this isolation compartment". Chrome extensions have that mo
+1 to Anne's suggestion. The current design is pretty terrible for API
performance. I think a request to / with OPTIONS or something, with a
response that requires some server side logic (like return the random
number UA just sent) is pretty darn secure.
cheers
dev
On 17 February 2015 at 11:24,
16 matches
Mail list logo
