On Fri, Oct 2, 2009 at 10:23 AM, Nick Fitzsimons <n...@nickfitz.co.uk> wrote:
>
> 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.
>
Thanks, Nick. Yes, that seems like a very good approach.
