XmlHttpRequest not loading latest version of xml

[James]

function loadXMLDoc(url, GoAsync)
{
var t = new Date();
var dummy = t.getTime();
var newUrl;
if(url.indexOf("?")>-1) newUrl = url + "&dummy=" + dummy;
else newUrl = url + "?dummy=" + dummy;

...

}

Please visit http://www.logicwebsolutions.com

James

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 11/29/2005 9:54 AM:

Nick wrote:

[in PHP, header() only works if there was no previous output.]

Not entirely true.

 

[Matt Silberstein]

It is not the request that is cached but the resource retrieved, hence the
_response_ previously sent. Which is why GET and POST request make no
difference here.


No, that Dirty Hack will only fill the user's cache with obsolete
data over time. <URL:http://www.mnot.net/cache_docs/>

That is a rather nicely written (and nice looking as well, easy to
read for a technical document). I have a quick question regarding some
of the debate here: have you tested (or read about tests) of this in
various browsers. I see discussion of specifications, but not of
various implementations except for Apache. That does not answer
enough.

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 11/29/2005 9:54 AM:

[in PHP, header() only works if there was no previous output.]

Not entirely true.

,-<URL:http://php.net/manual/en/function.header.php>
|
| Remember that header() must be called before any actual output is sent,
| either by normal HTML tags, blank lines in a file, or from PHP. It is a
| very common error to read code with include(), or require(), functions,
| or another file access function, and have spaces or empty lines that are
| output before header() is called. The same problem exists when using a
| single PHP/HTML file.

Maybe you are referring to this:

| <?php
| header("HTTP/1.0 404 Not Found");
| ?>
|
| Note: The HTTP status header line will always be the first sent to the
| client, regardless of the actual header() call being the first or not.
| [...]

However, additional header() calls, including sending issueing HTTP status
headers do not qualify as "(actual) output" here.


X-Post & F'up2 comp.lang.php

PointedEars

 

[Matt Silberstein]

I know this has been a long running debate in this group and I think I
understand the claims and theory on both sides. But to check as I see
the question if I have control of both sides (and have perfect systems
in between) then having an expiration string would be the best answer.
The owner of the data would know when it expires and the caches would
give me optimal performance. If the server does not expire the
information and/or the systems in-between are not set up right, then
the cached information could be incorrect. In that case I would have
to use a unique string to force freshening of the data. This, however,
could lead to excessive load on the various caching systems, from the
proxies to the client itself.

Assuming the above is substantially correct I have three questions.

First, does anyone have a reference to some tests on proxy
configuration? I saw people say that they can/are misconfigured, but I
would like to see something that gives me an idea of how prevalent
that is.

Second, as a follow up to that, does anyone have any ideas of what is
the realistic length of time things tend to stay in various caches
(proxy, client, etc.)? I know the answer could be "forever", I am just
wondering about expectation. Are we talking about minutes, hours,
days?

Third, couldn't the client check the expires itself and then decide on
asking a second time with a unique string? Yes, I understand that is
probably worthwhile for any/most situations, I am just trying to
understand this fully for myself.


Thanks to all.


--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Thomas 'PointedEars' Lahn]

I know this has been a long running debate in this group and I think I
understand the claims and theory on both sides. But to check as I see
the question if I have control of both sides (and have perfect systems
in between) then having an expiration string would be the best answer.

No. If that were so, you should definitely use all HTTP/1.1 cache-control
mechanisms available.

The owner of the data would know when it expires

Would they? I say, that depends on the resource.

and the caches would give me optimal performance.

If you knew the approximate future expiration date and it is an HTTP/1.0
cache, yes. If you set the Expires header to the current or a past date
for an HTTP/1.0 cache, no.

If the server does not expire the information and/or the systems
in-between are not set up right, then the cached information could
be incorrect. In that case I would have to use a unique string to
force freshening of the data.

You may have to use that, but with broken systems there is no guarantee
that this will work either. Arguing that intermediary implementations
could be broken and cache control therefore will not work, is completely
pointless.

This, however, could lead to excessive load on the various caching
systems, from the proxies to the client itself.
Correct.

Assuming the above is substantially correct I have three questions.

First, does anyone have a reference to some tests on proxy
configuration? I saw people say that they can/are misconfigured, but I
would like to see something that gives me an idea of how prevalent
that is.

I also wonder if anybody claiming this boldly can prove it, and more
important, can prove that this particular version and/or misconfiguration
is really used now by well-known ISPs. I seriously doubt it.

Second, as a follow up to that, does anyone have any ideas of what is
the realistic length of time things tend to stay in various caches
(proxy, client, etc.)? I know the answer could be "forever", I am just
wondering about expectation. Are we talking about minutes, hours,
days?

Minutes and hours would be hardly reasonable; remember that a cache should
provide for transparent faster data access. It is probably days, maybe
some weeks, given that a proxy cache is also of finite size (thus the
oldest, biggest or most seldom accessed ressources are inevitably removed
from it some day) and a proxy server usually has to provide service for a
larger number of users.

Third, couldn't the client check the expires itself and then decide on
asking a second time with a unique string?

It could. But you cannot use client-side JS scripting for this. Due to
security reasons including maintaining user privacy, the cache cannot be
accessed directly through the AOM.


PointedEars

 

[Matt Silberstein]

No. If that were so, you should definitely use all HTTP/1.1 cache-control
mechanisms available.

That is what I meant.

Would they? I say, that depends on the resource.

If anyone would, the owner of the data would know if it is old. If
not, then who would? Your solution certainly assumes it.

If you knew the approximate future expiration date and it is an HTTP/1.0
cache, yes. If you set the Expires header to the current or a past date
for an HTTP/1.0 cache, no.

You may have to use that, but with broken systems there is no guarantee
that this will work either. Arguing that intermediary implementations
could be broken and cache control therefore will not work, is completely
pointless.

Not really since in the real world we can figure out in what ways
things are usually broken. It may be that anything can happen in which
case we are sunk. Or it may be that they tend to be broken in ways we
can deal with.

I also wonder if anybody claiming this boldly can prove it, and more
important, can prove that this particular version and/or misconfiguration
is really used now by well-known ISPs. I seriously doubt it.


Minutes and hours would be hardly reasonable; remember that a cache should
provide for transparent faster data access. It is probably days, maybe
some weeks, given that a proxy cache is also of finite size (thus the
oldest, biggest or most seldom accessed ressources are inevitably removed
from it some day) and a proxy server usually has to provide service for a
larger number of users.

Again, there should be some real-world tests out there but I don't
know where to look.

It could. But you cannot use client-side JS scripting for this. Due to
security reasons including maintaining user privacy, the cache cannot be
accessed directly through the AOM.

I am not suggesting looking at the cache but at the expiration in the
header. See what the server sends you and make a guess on whether or
not it really was new. For critical data this is not necessarily a bad
solution.

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Jim Ley]

I also wonder if anybody claiming this boldly can prove it, and more
important, can prove that this particular version and/or misconfiguration
is really used now by well-known ISPs. I seriously doubt it.

There is just such a broken cache in the EMEA part of one of the
largest computer systems company in the world.

There are a lot more caches in corporates than there are ISPs.

It could. But you cannot use client-side JS scripting for this. Due to
security reasons including maintaining user privacy, the cache cannot be
accessed directly through the AOM.

Client-side JS can absolutely be used for this in the instance of
xmlhttp request requests which the OP was doing.

Jim.

 

[Thomas 'PointedEars' Lahn]

There is just such a broken cache in the EMEA part of one of the
largest computer systems company in the world.

That is a statement, not a proof.

Which company do you mean exactly? In case you mean IBM ("EMEA" still
has that ring to me): I worked for IBM Germany until about two months
ago and never had problems with cached resources accessed from within
the intranet. Not with IE 6 and not with Firefox 1.0.x; both on Win2k
SP-4.

There are a lot more caches in corporates than there are ISPs.

That is another statement.

Client-side JS can absolutely be used for this in the instance of
xmlhttp request requests which the OP was doing.

Correct. Fortunately, you preserved the context of my statement.
I referred to accessing the (local) cache directly. Of course, the
getResponseHeader() method of the XMLHttpRequest object used allows
to retrieve values of cache control headers like Expires and to
consider them for additional request (if the header was missing.)

BTW: My website uses cache control methods, including
<URL:http://www.pointedears.de/scripts/js-version-info> and
<URL:http://www.pointedears.de/scripts/test/mime-types/>
I update both presumably in intervals of less than two weeks.
You are welcome to test.


PointedEars

 

[Jim Ley]

That is a statement, not a proof.

well, I can't prove it to you other than by violating the security of
the company, can I?

Which company do you mean exactly? In case you mean IBM

Nope, not IBM, but a similar company.

That is another statement.

Do you dispute it?

Jim.

 

[Thomas 'PointedEars' Lahn]

well, I can't prove it to you other than by violating the security of
the company, can I?

Well, you could describe the situation as detailed as you are permitted to.

Nope, not IBM, but a similar company.

Name it then. And I would appreciate it if you marked omissions
in quoted material.

Do you dispute it?

Not yet. But it will be even harder to prove.


PointedEars

P.S.: I repaired the broken Subject header now.

 

[Matt Kruse]

That is a statement, not a proof.

I suspect that no amount of 'proof' would be adequate to satisfy you.

I think both sides of this argument have been laid out pretty well, and
anyone wanting to explore the topic could read through the thread and come
to their own conclusion.

 

[Matt Silberstein]

I suspect that no amount of 'proof' would be adequate to satisfy you.

I think both sides of this argument have been laid out pretty well, and
anyone wanting to explore the topic could read through the thread and come
to their own conclusion.

The only thing missing is I wish that I had some kind of numbers to
work on. I have one side asserting there is major problem with
misconfigured systems, another telling me it is not so, but I lack any
information to make a determination. And I know I can't do a
sufficient test on my one. Again, does any know of any reference to
this being tested?


--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Matt Kruse]

The only thing missing is I wish that I had some kind of numbers to
work on.

Stats which surely will never be available.

I have one side asserting there is major problem with
misconfigured systems

I don't believe that was the point being made.

From my point of view, the point was that even if there is just one user
behind a broken caching proxy, changing the url will make it work for
everyone including that one user. You might not know for certain if you will
have a user behind a broken proxy, but if you want to play it safe you
change the url to cater to the lowest common denominator.

A specific case isn't required. In theory, such a situation could exist (and
has been _known_ to exist at various times). Since the risk of such a
situation is > 0, you can completely hedge against the risk by using the
unique url strategy.

 

[Jim Ley]

Well, you could describe the situation as detailed as you are permitted to.

The situation has been described already resources are cached despite
them being asserted to be non-cacheable.

Name it then.

Unfortunately there is such a thing as client confidentiality...

Jim.

 

[Randy Webb]

Matt Silberstein said the following on 12/3/2005 3:45 PM:

The only thing missing is I wish that I had some kind of numbers to
work on. I have one side asserting there is major problem with
misconfigured systems, another telling me it is not so, but I lack any
information to make a determination. And I know I can't do a
sufficient test on my one. Again, does any know of any reference to
this being tested?

One hundred trillion trillion examples of something working won't prove
a theory but one example of it not working will dis-prove it. The AOL
Proxies routinely disregard cache headers. Now, you have to decide
whether you want to take that into account, and work around it as has
been explained many times by appending to the URL. Or, you say to heck
with ~40 million potential customers and you rely on server headers.

 

[Matt Silberstein]

Matt Silberstein said the following on 12/3/2005 3:45 PM:

One hundred trillion trillion examples of something working won't prove
a theory but one example of it not working will dis-prove it. The AOL
Proxies routinely disregard cache headers. Now, you have to decide
whether you want to take that into account, and work around it as has
been explained many times by appending to the URL. Or, you say to heck
with ~40 million potential customers and you rely on server headers.

I don't understand. You seem to object to my asking for numbers, then
give me some numbers to prove your point. I agree that if AOL will
"frequently" get it wrong then that is a sufficient argument. I am
quite willing to abandon one theoretically existent user, but not 40M.
While I believe you is there any published information on this?


--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Randy Webb]

Matt Silberstein said the following on 12/3/2005 10:21 PM:

I don't understand. You seem to object to my asking for numbers, then
give me some numbers to prove your point.

I had no objection to you asking for numbers.

I agree that if AOL will "frequently" get it wrong then that is a
sufficient argument. I am quite willing to abandon one theoretically
existent user, but not 40M.

While I believe you is there any published information on this?

Not that I am aware of that is published on the web. I do know, from
personal experience, that it can take up to 3 full days for a new page
to propogate through the AOL proxies.

 

[Matt Silberstein]

Matt Silberstein said the following on 12/3/2005 10:21 PM:

I had no objection to you asking for numbers.

True so let me re-phrase: you seem to think that the numbers were not
an important decision point. That is, it was more important to ensure
that the one person was ok than just program for the 10^X. I think
that is a judgment call, not an absolute. Paranoia is the appropriate
approach, but it will only take you so far.

Not that I am aware of that is published on the web. I do know, from
personal experience, that it can take up to 3 full days for a new page
to propogate through the AOL proxies.

Even with appropriate header? Wow!

(As a real aside, but telling about misconfiguration, I once had some
Internet email show up 6 months after sending it. It had some tech
advice that was almost disastrous since it was so displaced in time.)

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

 

[Randy Webb]

Matt Silberstein said the following on 12/4/2005 11:58 AM:

On Sun, 04 Dec 2005 01:31:47 -0500, in comp.lang.javascript , Randy
Webb <[email protected]> in




True so let me re-phrase: you seem to think that the numbers were not
an important decision point. That is, it was more important to ensure
that the one person was ok than just program for the 10^X. I think
that is a judgment call, not an absolute. Paranoia is the appropriate
approach, but it will only take you so far.

To me, no, the numbers are not that important because most statistics on
the web are generally useless simply because of the nature of the web.
There is no way to come up with reliable numbers on what ISP's honors
what headers without testing every one of them, almost daily, to cover
an changes that are made at any given time.

My numbers were more a point that while you may not be able to prove
something, it is quite easy to disprove something.

Even with appropriate header? Wow!

Yes, even with appropriate headers. The AOL combo didn't even honor a
Control-F5 Refresh to get it from the server after clearing the cache.
It got it from an AOL proxy that was outdated.

(As a real aside, but telling about misconfiguration, I once had some
Internet email show up 6 months after sending it. It had some tech
advice that was almost disastrous since it was so displaced in time.)

That sounds like AOL Tech support