Bug Tracker

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#7621 closed feature (wontfix)

JSONP cacheability

Reported by: matas Owned by: jaubourg
Priority: low Milestone: 1.next
Component: ajax Version: 1.5.2
Keywords: needsreview, ajaxrewrite Cc: snover, ajpiano, slexaxton, dmethvin, addyosmani
Blocked by: Blocking:


would be nice to have a simpler way of generating JSONP requests with static callback. basically preventing it from generating urls with random callback names. I know, it can be passed in the url string directly, but I'd prefer cache:true option to have the same effect for example.

sorry, if I'm not clear enough.

Change History (12)

comment:1 Changed 8 years ago by Rick Waldron

Resolution: worksforme
Status: newclosed

You can define the callback name in your options...

This is copied from: http://api.jquery.com/jQuery.ajax/

jsonpCallbackString Specify the callback function name for a jsonp request. This value will be used instead of the random name automatically generated by jQuery. It is preferable to let jQuery generate a unique name as it'll make it easier to manage the requests and provide callbacks and error handling. You may want to specify the callback when you want to enable better browser caching of GET requests.

comment:2 Changed 8 years ago by Rick Waldron

Resolution: worksforme
Status: closedreopened

comment:3 Changed 8 years ago by Rick Waldron

Owner: set to matas
Status: reopenedpending

Matas, we can reopen. Can you provide some use cases? Examples or even a branch with this feature patched in?

comment:4 Changed 8 years ago by matas

Status: pendingnew

this is my very rough initial proposal: https://github.com/mataspetrikas/jquery/commit/52d806660183866840cc6b53343fa870851b48e6

we could probably do some url hashing making the callback naming potentialy shorter. also it could be optional. what would be the most jquery-like way to pass this option then? somethign like this maybe: https://github.com/mataspetrikas/jquery/commit/85416f01683e872da11e25ee7b09f0115092e0ae

I'm not sure about the code at line 269 though :/

anyway this change would make many public APIs happy, allowing them to cache the JSONP responses instead of going to db each time only because jQuery generated a random request string.

what do you think abou it?

comment:5 Changed 8 years ago by Rick Waldron

Cc: snover ajpiano slexaxton dmethvin addyosmani added
Component: unfiledajax
Keywords: needsreview added
Priority: undecidedlow
Status: newopen

Thanks Matas - glad you brought this to my attention to re-open, I think I missed the value the first time. I'm going to pull this into a local branch and play around. Also, cc'ing everyone else, hopefully they'll do the same.

comment:6 Changed 8 years ago by jaubourg

The real issue here is when you have requests with the same callback name running concurrently (which is prone to happen).

I implemented the "constant callback" trick in jquery-jsonp: http://code.google.com/p/jquery-jsonp/ (and also added a pageCache option for reluctant services that simply never issue 304 responses for jsonp requests).

However, I refrained from adding it into the Ajax rewrite because of... drum roll... IE and also some fairly ugly $.browser checks all around.

Everything is explained on my blog for the curious: http://www.jaubourg.net/2010/07/loading-script-as-onclick-handler-of.html.

After having battled quite a lot, I came to reason and now think jQuery should have a viable and clean jsonp implementation while users with advanced needs can/should use a plugin.

comment:7 Changed 8 years ago by Rick Waldron

Keywords: ajaxrewrite added

comment:8 Changed 8 years ago by anonymous

I just want to add a note of support for a fix to this issue.

I'm using jsonpCallbackString just to gain browser caching of the cross-domain requests. The fact that using jsonpCallbackString means the success/failure/complete callbacks don't get called is causing me some pain. The jsonpCallbackString docs don't mention this 'feature'. If I could gain caching without using jsonpCallbackString I'd be delighted.

comment:9 Changed 8 years ago by john

Milestone: 1.next
Version: 1.5.2

Matas' particular patch seems quite interesting and a relatively painless addition, I think we should consider it.

comment:10 Changed 8 years ago by john

Owner: changed from matas to jaubourg
Status: openassigned

comment:11 Changed 8 years ago by jaubourg

It's painless but completely wrong. If you have two concurrent jsonp requests with the same callback name, you cannot differentiate between the two of them (as I explained earlier): to handle concurrent requests you have to code an entirely different logic which involves a script tag injection technique that is entirely different to what is done in the script transport ( see jQuery-JSONP http://code.google.com/p/jquery-jsonp/source/browse/trunk/core/jquery.jsonp.js#171 ).

The technique used is described here: http://jaubourg.net/2010/07/loading-script-as-onclick-handler-of.html

Since the rewrite, setting the jsonpCallback option doesn't hinder the success/failure/complete callbacks (they are still fired). So it's safer to let application code decide when to use a fixed callback name and make sure there are no concurrent requests with a given callback name in the application logic.

We could introduce a jQuery-JSONP like solution (it's possible to feature-detect stuff -- dodgily but heh) but is the amount and duplication of code worth the effort, knowing setting the jsonpCallback option will do the trick anyway provided the application is careful about concurrent requests?

Last edited 8 years ago by jaubourg (previous) (diff)

comment:12 Changed 8 years ago by john

Resolution: wontfix
Status: assignedclosed

Ok, so based upon jaubourg's comment, I'm going to close this.

Note: See TracTickets for help on using tickets.