Using a fixed parameter name for the caching bypass parameter

[GoogleCodeExporter]

The normal jQuery.ajax function, in order to disable caching adds a parameter 
"_=<TIMESTAMP>".

The jQuery.jsonp function instead creates a parameter "_<TIMESTAMP>=" to 
perform the same effect.

The advantage of the _=<TIMESTAMP> approach is that the parameter name remains 
constant - this means that when building up reports based on access logs, etc. 
it is substantially simpler to filter it out (just remove the parameter '_').

I've provided a patch to implement this change, which I use locally.

Original issue reported on code.google.com by andre...@gmail.com on 2 Sep 2010 at 9:39

Attachments:

• cachechange.patch

[GoogleCodeExporter]

Sorry for the delay in replying to the bug, been moving and didn't have access 
to the interweb... anyway...

I took the variable parameter name route purporsedly, the idea being not to end 
up at the mercy of a data api provider with a "_" parameter (would be stupid on 
the provider's part, but I've seen stupid already). Doesn't your filtering 
technique support regexps like _[0-9]* to catch both $.ajax() and $.jsonp()?

I *could* add an option but I'm surprised the _<TIMESTAMP> parameters are 
proving so resilient in the logs ;)

Original comment by aubourg.julian on 20 Sep 2010 at 11:16

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

It was more than just logging -- I had put a server-side caching system (so 
that multiple users requesting the same data can share the same results) into 
an application, but the caching layer doesn't know what parameters to expect -- 
they can be variable.  As such, the caching layer knows to filter out the 
parameter called 'callback' and the parameter called '_' - as that's what the 
other JSON libraries use.  I'd just have thought it clearer if the two ways of 
sending jsonp messages (through the inbuilt jquery.json and your jquery.jsonp 
plugin) appeared at the system level in the same way?

If you prefer, I'll modify my application to filter out all '_' parameters 
within the caching layer.

Original comment by andre...@gmail.com on 22 Sep 2010 at 8:22

[GoogleCodeExporter]

It's much clearer now, thanks.

It seems the simplest solution is to filter out every _[0-9]* parameters 
server-side. Again, I'm more than willing to add to the plugin but it seems 
like quite a specific use-case to me.

Original comment by aubourg.julian on 23 Sep 2010 at 11:06

[GoogleCodeExporter]

I'll modify it server side -- and hope nobody does something silly like create 
a _[0-9]* parameter (parameter names are out of my control) :)

As far as I'm concerned - feel free to close off this.

Original comment by andre...@gmail.com on 23 Sep 2010 at 11:27

[GoogleCodeExporter]

OK, closing then.

Original comment by aubourg.julian on 2 Oct 2010 at 3:02

• Changed state: WontFix