IIS6 caching
M. M. Rafferty
caching and continuing to server old content after the source files has been
edited.
Initially the hosting client contacted us and it appeared to be a caching
issue on there end. There was no indication in the webserver log that there
had been a recent request from their IP for the involved pages. I was able
to bring up the pages and see the changed content. We decided it was simply
a client site or proxy caching issue.
Today, we received a second frantic call. They were still having problems
with the caching and needed to have certain changes completed (legal
requirements.) No matter what they did, they were not seeing the revisions
which had been uploaded with the built-in IIS 6 FTP service. They had a
couple additional one line changes that needed to be made, and I used
notepad to edit their HTM file on the server. I had no trouble initially
seeing the change. But it wasn't quite right and when I went back to change
the file a second time, the changes just would not appear. I went through
the drill of clearing the browser cache. No change. I tried a different
browser and still no change. Tried from the web server itself and it was
also showing the old version. And in these cases, the web server logs were
showing the hits. I finally gave up and recycled their application.
Why is IIS not getting the message that the pages have changed? There is no
third party application to blame. Just NotePad and IIS/FTP being used. It
is not acceptable to have require the administrator to recycle the
application in order to get the latest changes by one of the hosting
clients' web developers to be served.
Is this a known issue with IIS 6? If so, is there a patch to correct it?
Thanks,
Mary Rafferty.
Egbert Nierop (MVP for IIS)
news:O90mZXkr...@tk2msftngp13.phx.gbl...
What do they upload? Static HTML or aspx pages? In the last case, ALSO the
bin directory needs to be uploaded with a new assembly.
In addition, your client is using IE to test it? Because depending on the
client type it might ask IIS to send an creation timestamp where the next
time, IIS might indicate that the content has not changed. If that is the
case, you should modify code to include a timestamp based on the assembly
Response.Cache... start here...
>
> Thanks,
> Mary Rafferty.
>
>
M. M. Rafferty
extension.
The problem with observed with Mozilla on my workstation as well as IE on
the server -- neither one of which had ever been used to view the site
previously. The caching was not in the browser. There was no proxy server
involved. IIS 6 was serving stale content.
"Egbert Nierop (MVP for IIS)" <egbert...@nospam.invalid> wrote in
message news:%23UObRcq...@TK2MSFTNGP10.phx.gbl...
Egbert Nierop (MVP for IIS)
> The pages in question where plain HTML -- static pages with a ".htm"
> extension.
>
> The problem with observed with Mozilla on my workstation as well as IE on
> the server -- neither one of which had ever been used to view the site
> previously. The caching was not in the browser. There was no proxy
> server
> involved. IIS 6 was serving stale content.
Did you enable compression?
http://support.microsoft.com/?id=319384
--
compatible web farm Session replacement for Asp and Asp.Net
http://www.nieropwebconsult.nl/asp_session_manager.htm
M. M. Rafferty
"Egbert Nierop (MVP for IIS)" <egbert...@nospam.invalid> wrote in
message news:ObkeCXwr...@TK2MSFTNGP12.phx.gbl...
David Wang [Msft]
notification. i.e. is it on a hard drive in the machine itself or some
network-attached storage device.
On the server side, IIS6 will cache static files in kernel mode response
cache (if you request it 3 times within 10 seconds). These entries are
invalidated after either 120 seconds of non-access (configurable), cache is
full, w3wp is recycled, or triggered eviction (file change notification
controls this).
Please verify that you did not scriptmap .htm extension to some ISAPI which
is implementing some other invalidation policy -- so that we are certain
that it is only Static File invalidation logic that is under discussion.
Please also verify that these "Stale" hits all show up in PerfMon as
kernel-mode cache hits (select Web Service Cache\Kernel: URI Cache
Hits/Misses). Cache hits obviously still show up in the log files -- I need
help from you to show whether the request was a kernel-mode cache hit or
generated by IIS in user mode.
There are a couple of caching-related bugs that will be released with
WS03SP1. I do not know if any of them apply to your situation nor are they
packaged for QFE (so that you can ask for them by QFE#). Contacting PSS is
the only sure way to figure that out.
The reason why we do not immediately publish patches for all bugs fixed is
support. Fixing and immediately publishing a mere 10 bugs will create 1024
different variations to support. You will notice the QFE releases are all on
a "as-needed" basis to fix specific issues -- it is not thoroughly regressed
until released in the encompassing SP.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"M. M. Rafferty" <m...@vistagrande.com> wrote in message
news:%23fd5q3y...@tk2msftngp13.phx.gbl...
M. M. Rafferty
Yes, all the files are on a local drive. And no, there is no other script
mapping being done for HTM files. The site where this problem was observed
is busy enough that the pages could be having multiple hits within a 10
second period.
As a result of additional searches I found KB article 832139 which seemed to
match the situation since we do have an IP and host header configuration for
that site. I contacted support for the hotfix which seems to have cured the
problem.
By the way, is there any ETA on SP for Windows 2003?
"David Wang [Msft]" <som...@online.microsoft.com> wrote in message
news:ewy8ypAs...@TK2MSFTNGP09.phx.gbl...
David Wang [Msft]
I do not have an ETA on Windows Server 2003 SP1.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"M. M. Rafferty" <m...@vistagrande.com> wrote in message
news:uTmkYlKs...@TK2MSFTNGP10.phx.gbl...