+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,
> 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
> 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
> 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
>
> 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
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
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
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
>
> 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
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
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
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
>
> 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
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:
>>
>>
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
> 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
16 matches
Mail list logo