Skip to main content

Bug Tracker

Side navigation

#7621 closed feature (wontfix)

Opened November 24, 2010 04:10PM UTC

Closed April 16, 2011 10:21PM UTC

Last modified March 13, 2012 08:12PM UTC

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:
Description

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.

Attachments (0)
Change History (12)

Changed November 24, 2010 04:15PM UTC by rwaldron comment:1

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.

Changed November 24, 2010 06:57PM UTC by rwaldron comment:2

resolution: worksforme
status: closedreopened

Changed November 24, 2010 06:58PM UTC by rwaldron comment:3

owner: → matas
status: reopenedpending

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

Changed November 26, 2010 09:46AM UTC by matas comment:4

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?

Changed November 26, 2010 02:49PM UTC by rwaldron comment:5

cc: → snover, ajpiano, slexaxton, dmethvin, addyosmani
component: unfiledajax
keywords: → needsreview
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.

Changed December 01, 2010 01:53AM UTC by jaubourg comment:6

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.

Changed December 27, 2010 10:37PM UTC by rwaldron comment:7

keywords: needsreviewneedsreview,ajaxrewrite

Changed January 12, 2011 10:08PM UTC by anonymous comment:8

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.

Changed April 16, 2011 08:56PM UTC by john comment:9

milestone: → 1.next
version: → 1.5.2

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

Changed April 16, 2011 09:09PM UTC by john comment:10

owner: matasjaubourg
status: openassigned

Changed April 16, 2011 09:55PM UTC by jaubourg comment:11

_comment0: 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 ). \ \ 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?1302991090434107

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?

Changed April 16, 2011 10:21PM UTC by john comment:12

resolution: → wontfix
status: assignedclosed

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