HELP: IIS6 pernamently caches XSL uri and won't change!! woes ...

[Andrew Wan]

Okay, this is really weird. We have two Windows 2003 Server SP1 PCs. One
hosts IIS6 website, and the other hosts our DCOM service program. Our
website is ASP/XSL. An ASP page uses Msxml2.DOMDocument.4.0 to transform a
XML top node via XSL stylesheet outputting to HTML. We have set up the
website on-site successfully with no problems. However, when we upgraded our
client some how IIS6 still references a really old XSL file. No matter how
many times we restart Windows 2003 Server or IIS6, somehow the old XSL file
is still being used. I then found out about "Lazy Delay Propagation for ASP
pages". I checked the registry and it's already disabled. I then found out
about "Uri caching". I disabled that. Still no luck. Why is IIS6 still
referencing the old XSL file?

Even when I remove the "virtual directory" from IIS6, I can't
modify/rename/delete the actual folder that it was pointing to.

Does anyone know whether there's a conflict issue with IIS6 & MSXML 4.0? And
no we can't use MSXML 6.0 yet due to our service program using 4.0.

[Jeje]

maybe the XSL file is cached on the client side.
try to purge the cached file in IE
and change the http header options to limit the cache duration in IIS.

"Andrew Wan" <an************@hotmail.comwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...

Okay, this is really weird. We have two Windows 2003 Server SP1 PCs. One
hosts IIS6 website, and the other hosts our DCOM service program. Our
website is ASP/XSL. An ASP page uses Msxml2.DOMDocument.4.0 to transform a
XML top node via XSL stylesheet outputting to HTML. We have set up the
website on-site successfully with no problems. However, when we upgraded
our client some how IIS6 still references a really old XSL file. No matter
how many times we restart Windows 2003 Server or IIS6, somehow the old XSL
file is still being used. I then found out about "Lazy Delay Propagation
for ASP pages". I checked the registry and it's already disabled. I then
found out about "Uri caching". I disabled that. Still no luck. Why is IIS6
still referencing the old XSL file?

Even when I remove the "virtual directory" from IIS6, I can't
modify/rename/delete the actual folder that it was pointing to.

Does anyone know whether there's a conflict issue with IIS6 & MSXML 4.0?
And no we can't use MSXML 6.0 yet due to our service program using 4.0.

[David Wang]

If you restart IIS6 and it's still cached, then IIS6 is not the cause
of your issue.

The settings you checked, "Lazy Delay Propagation for ASP pages" and
"Uri caching", have no connection nor relevance to XSL file caching,
so it does not surprise me that it did nothing for your observations.

Given an HTTP request, there are MANY things that can cache it -- not
just the web server.

In your case, you probably want to look at client-side caching or
network-caching because you've already eliminated web server caching.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Feb 16, 12:23 pm, "Andrew Wan" <[e-mail]:

Okay, this is really weird. We have two Windows 2003 Server SP1 PCs. One
hosts IIS6 website, and the other hosts our DCOM service program. Our
website is ASP/XSL. An ASP page uses Msxml2.DOMDocument.4.0 to transform a
XML top node via XSL stylesheet outputting to HTML. We have set up the
website on-site successfully with no problems. However, when we upgraded our
client some how IIS6 still references a really old XSL file. No matter how
many times we restart Windows 2003 Server or IIS6, somehow the old XSL file
is still being used. I then found out about "Lazy Delay Propagation for ASP
pages". I checked the registry and it's already disabled. I then found out
about "Uri caching". I disabled that. Still no luck. Why is IIS6 still
referencing the old XSL file?

Even when I remove the "virtual directory" from IIS6, I can't
modify/rename/delete the actual folder that it was pointing to.

Does anyone know whether there's a conflict issue with IIS6 & MSXML 4.0? And
no we can't use MSXML 6.0 yet due to our service program using 4.0.