simple ajax does not work in firefox - won't pass variable, ie fine

[spewn]

here's my code:

function runclist(a) {
http.open('get', 'get-c.pl');
 http.onreadystatechange = CListResponse;
 http.send('x='+a);
}

function CListResponse() {
 if(http.readyState == 4){
 response = http.responseText;
 document.getElementById('clist').innerHTML=response;
 }
}

this code passes the value of 'a' fine in IE, but in firefox, doesn't seem to be passing the value...at all.

the issue seems to be in the "http.send('x='+a);" part.

even if i put "http.send('x=test');", still nothing.

any ideas?

thanks!

 

[BabyJeffy]

Does this work for you (since you are using GET)?

function runclist(a) {
http.open('get', 'get-c.pl[!]?x='+a[/!]);
 http.onreadystatechange = CListResponse;
 http.send([!]null[/!]);
}

Cheers,
Jeff

[tt]Visit my blog [!]@[/!]

http://www.coderambler.com/

Visit Code Couch [!]@[/!]

http://www.codecouch.com/

[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094

 

[spewn]

if i do that, which i've tried, it works, but the information becomes static if the same information is passed...

for instance, i am operating the script on a dropdown. so the first time i drop down to value 2, the ajax code runs and hit's the server, but the second time i choose value 2, the information is cached and the script does not call the server file.

the way around it was to pass the values in http.send(), which keeps the info fresh each time i select value 2.

but it doesn't pass in firefox.

someone suggested messing with the server headers, but i'm so new to this, i couldn't figure it out.

i've looked around, but i can't figure this one out.

what do you think?

- g

 

[spewn]

okay...i went with your suggestion, but i figured out how to keep it fresh...

here's my solution...

rn=Math.floor(Math.random()*99999)
http.open('get', 'get-c.pl?x='+a+'&y='+rn);

as you can see, appending the query string with a random number assures me that even if i call the same value for x, the value for y should be different each time.

and it works.

i still would like to do it the right way, but this way works.

thanks.

- g

 

[BillyRayPreachersSon]

Another way would be to use a cache-control response header at the server-end to always ensure the returning data is never cached.

This allows for restful URLs, should your solution require them, whereas adding a cachebuster parameter does not.

Hope this helps,
Dan




Coedit Limited - Delivering standards compliant, accessible web solutions

Dan's Page [blue]@[/blue] Code Couch:

http://www.codecouch.com/dan/

Code Couch Tech Snippets & Info:

http://www.codecouch.com/

 

[spewn]

would you mind elaborating on these two points?

cache-control response header at the server-end

and...

restful URLs

i am interested in doing it the right way.

thanks.

- g

 

[BillyRayPreachersSon]

No problem, although it might be quite a simplistic explanation, as I'm no HTTP protocol guru

When a web server sends a response back to the browser (whether a whole web page, or a page fragment via AJAX), there are various headers that can be sent as well. One of these is the 'Cache-Control' header.

This header can have various values, one of which is 'no-cache'. This tells the browser that it should not cache the content being sent to it, so that next time it is requested, it will always have to get a new version (as there is no previous version in its cache).

Now, as you've already seen, there is no need to use this if you are OK passing a cachebuster parameter through, as it will have much the same effect because the URL being requested is different every time (see footnote).

There will be times when passing a cachebuster parameter is not desirable, however. For example, if your application server sits behind a caching layer, you wouldn't want the URL to be different every time for idempotent requests, as the cached version would never get used, and so your application server would get a direct hit every time.

Now, I'm not going to say that using cachebusters is wrong, and I'm not going to say that you shouldn't be using them. They do work, and they require no server-side modification.

So, it's not really about 'doing it the right way', but more about doing it the right way for your requirements.

If you don't get 30,000 hits an hour and have no caching layer, then you will probably be fine with the cachebuster, although setting the response header will also work.

I think that it boils down to this: If you know that the cachebuster will have a performance hit on your setup, then don't use it, otherwise use whichever method you prefer

Should you wish to use the response header, you'd need to ask in the forum for whichever server-side technology you are using (e.g. PHP, ASP, JSP, etc) for information on how to set it.

Hope this helps,
Dan


Footnote: Your example above uses random numbers, which are not guaranteed to be unique, so could still cause problems. If you wanted to stick with the client-side method, I'd switch to using the number of milliseconds since the epoch:

rn = new Date().getTime();

This will always be unique per PC, unless you change the clock settings.



Coedit Limited - Delivering standards compliant, accessible web solutions

Dan's Page [blue]@[/blue] Code Couch:

http://www.codecouch.com/dan/

Code Couch Tech Snippets & Info:

http://www.codecouch.com/