changes in HTML code are ignored by IE6

  • Thread starter Thread starter aa
  • Start date Start date
A

aa

I do write some HTML/Javascript code and since recently changes in the code
are ignored by "Refresh"
I reload my w2k.


When I looked into VIEW-->Source code, the source code shows the result of a
javascript code execution, not the javascript code itself as it is supposed
to be.

"Check for new versions of stored pages" in Internet options is set to
"Every visit to the page".
Temporary internet files have been deleted.

Did I accidentally changed something in my browser settings?
 
aa said:
I do write some HTML/Javascript code and since recently changes in the code
are ignored by "Refresh"
I reload my w2k.


When I looked into VIEW-->Source code, the source code shows the result of a
javascript code execution, not the javascript code itself as it is supposed
to be.

Where is this JavaScript code execution supposed to take place?
I would not expect View Source to always show you raw source.
Use the TIF viewer to see that, if it is cacheable. (Alt-T,O,Alt-S,V)
Notice that in the case of frames, right-click View Source is different
from Alt-V,c which shows the source of the frameset. However,
I don't see why a frameset couldn't be constructed dynamically too.

"Check for new versions of stored pages" in Internet options is set to
"Every visit to the page".
Temporary internet files have been deleted.

Do you suspect that the client is not receiving the new source at all?

The usual explanation (which is sometimes borne out by a user asking
the ISP) is that there must be an intermediate cache somewhere that
is hanging on to old content.

If you have cleared your TIF that is all that you can do. It would have
been sufficient just to press Ctrl-F5 for a Refresh. Either cause
HTTP requests to be issued which do not refer to previously seen
instances of the file being requested.

There are two suggested workarounds which will depend on the host
server's capability. You can try appending a question mark to your
request. The intent of that is to make the request look like a CGI input
which normally would not have a cached response available anywhere.
If your host server has a secure port open (e.g. 443) you could try
making your request with the https:// protocol prefix instead of the
http:// protocol prefix.

BTW a factor which could have some bearing on this is your browser's
settings for HTTP 1.0 or HTTP 1.1 protocol. Toggling that may be
worth a try.

Did I accidentally changed something in my browser settings?

Not likely. If you are sure of what you are looking at
ask your ISP to check for a broken cache.


Good luck

Robert Aldwinckle
---
 
Back
Top