2009/10/2 brian <bally.z...@gmail.com>:
>
> On Fri, Oct 2, 2009 at 5:00 AM, Nick Fitzsimons <n...@nickfitz.co.uk> wrote:
>>
>> 2009/10/2 Dave Methvin <dave.meth...@gmail.com>:
>>>
>>>> Is there some easy way of forcing IE to make ajax
>>>> calls?
>>>
>>> You can use the old trick of adding a random number to the end of the
>>> url.
>>
>> That's what the { cache: false } option does; see jQuery 1.3.2 line
>> 3448 onwards:
>>
>> if ( s.cache === false && type == "GET" ) {
>> var ts = now();
>> // try replacing _= if it is there
>> var ret = s.url.replace(/(\?|&)_=.*?(&|$)/, "$1_=" + ts + "$2");
>> // if nothing was replaced, add timestamp to the end
>> s.url = ret + ((ret == s.url) ? (s.url.match(/\?/) ? "&" : "?") +
>> "_=" + ts : "");
>> }
>>
>
> Could someone please explain to me the significance of "_=" in the URL?
>
It doesn't really have any significance as such, it's just a throwaway
name. In order to break browser caching, something needs to be added
to the query string which wasn't present on any previous request from
the same browser, and jQuery uses the current time in milliseconds
since the epoch date. A query string might already be present, with
various name-value pairs representing form elements (e.g.
http://example.com/foo?id=1&bar=baz). However, there is very little
chance somebody has a form element named "_", so that is used as the
name for the otherwise-irrelevant timestamp used to break caching; in
the previous example, the URL would change to something like
http://example.com/foo?id=1&bar=baz&_=987654321.
The only circumstances in which this could break is if somebody
already has a form element named "_", in which case the behaviour of
the server when faced with two values for the same field is
implementation-dependent (it's best if it makes an array of them, but
PHP for example is broken in this regard); or if an over-eager
server-side developer throws a validation error on encountering a
field they weren't expecting, in which case said developer should be
sent off to grow turnips for a living instead.
Regards,
Nick.
--
Nick Fitzsimons
http://www.nickfitz.co.uk/
