>
> There's something significant behind the buzz, though. I really don't want
> to read the announcement: "ATTN everyone using jQuery.ajax(). If you're
> going to update your library or if you're linking to the latest on google
> and it's updated FOR you without your knowledge, you MUST first go t
On Tue, 29 Dec 2009 22:52:45 +0100, Tobias Hoffmann
wrote:
[...]
> And with html and script blocks we already have the 'eval'-behavior
(which
> I
> did not think of in my original post).
[...]
But not until the moment the developer chooses to place it into the DOM
(when using $.ajax()). Granted,
Catching up on my emails...
On Tue, Dec 29, 2009 at 9:27 AM, Julian Aubourg wrote:
> If you're worried about your server sending malicious javascript, then only
>> accept text/plain or text/xml (*even dataType: 'html' isn't safe since it
>> executes script blocks*).
>>
>
Good point.
IMO auto-eva
On Tue, 29 Dec 2009 09:35:11 +0100, Julian Aubourg
[...]
>>
>> I'm beginning to wonder if we're not buzzing for nothing with this
>> conversation. Actually, not specifying a dataType could very well behave
>> as
>> a guess-anything system. In analogy to what you said with content-type,
>> setting a
This is good. #2 has solid support.
John, care to chime in this?
-- Sent from my Palm Prē
Julian Aubourg wrote:
So it was pure #2 obviously, not #1.
2009/12/29 Julian Aubourg
Again, why not do this with an Accept header?
Client
sends acceptable content types, serve
So it was pure #2 obviously, not #1.
2009/12/29 Julian Aubourg
> Again, why not do this with an Accept header?
>>
>> Client sends acceptable content types, server responds with a content
>> type, if the server's response is one of the accepted types, jQuery
>> processes accordingly, if not, jQue
>
> Again, why not do this with an Accept header?
>
> Client sends acceptable content types, server responds with a content type,
> if the server's response is one of the accepted types, jQuery processes
> accordingly, if not, jQuery returns data unprocessed.
>
> The dataType option should be for t
dataType does exactly what you're describing via one simple setting. It
sets accept headers for us and then translates the returned data for us,
all with a single word. That's what dataType is for. We want to continue to
use such a mechanism for easily handling such tasks.
On Mon, 28 Dec 2009 13
Actually, I think you are right in line with the rest of us.
Rick
On Mon, Dec 28, 2009 at 4:11 PM, Erik Beeson wrote:
> Again, why not do this with an Accept header?
>
> Client sends acceptable content types, server responds with a content type,
> if the server's response is one of the accepte
Again, why not do this with an Accept header?
Client sends acceptable content types, server responds with a content type,
if the server's response is one of the accepted types, jQuery processes
accordingly, if not, jQuery returns data unprocessed.
The dataType option should be for things that are
I can compromise with your #2, and give them both my vote.
Passing it on...
*1. Allow $.ajax() to accept multiple expected dataTypes.
2. Setting to have $.ajax() auto-detect/translate via response content-type
header.*
Julian - your thoughts?
On Mon, Dec 28, 2009 at 3:39 PM, webbiedave wrot
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But
>
> We're struggling with the best way to inform .ajax() that we expect
> multiple data types. Either, with a setting like "auto" or by passing an
> array of data types (or maybe allowing both).
>
Perhaps it would help if we defined a list of goals. I'll start.
1. $.ajax() - if dataType has not b
13 matches
Mail list logo