Content Expiration Question

Frankie · Aug 1, 2005

Using ASP.NET 1.1 and IIS 6... what is the effect of enabling Content
Expiration -- Expire Immediately?

Does it cause the files in the virtual directory to be served on every
single browser request even if the files do not change?

The reason I ask is that I was having trouble with a css file not getting
refreshed in the browser after the css file was updated on the server. In
testing I found that I could manually update the css file on the server (via
Notepad) and the browser would not get the updated CSS file. And yes, I
purged the cache, deleted local files, rebooted the local machine, tested in
a variety of browsers, etc. New browser sessions would continue to receive
the old version of the css file. The only thing I could reliably do to cause
the newly saved css file to be served was to recycle the App pool . The
hosting provider then enabled Content Expiration -- Expire Immediately and
that seems to solve the problem. My concern is that the css file(s) will now
get served up unnecessarily (i.e., even when they haven't been updated).

Thoughts? Suggestions?

Thanks!

Frankie · Aug 1, 2005

Oops! I spoke too soon.

Enabling content expiration does not solve the problem. That is, updated css
files are still not served to requesting clients.

Here's the only thing I have been able to do to reliably get new css files
to get served:
1. Recycle the application pool (via IIS Manager).

NONE of these things cause the current CSS file to go into effect:
1. Hitting F5 in IE
2. Hitting Shift + F5, nor Ctrl + F5
3. Deleting files in the browser (via Internet Options in IE)
4. Starting a new browser session
5. Rebooting the client and requesting the page again.
6. Restarting the ASP.NET Application (by saving an inconsequential change
to the app's Web.config)

Any ideas? Any direction for me to go to get more info to help narrow this
down?

Thanks!

Guest · Aug 1, 2005

Does your project in VS include these files? the directory in which they
reside?

If so, then they may not be resent to the client until the "application" is
recycled.

If they are included, right-click them in the solution explorer and
"exclude" them from the project. This will eliminate any dependency that the
application maintains about them but they can still be referenced by your
project. Otherwise the web server/ASP.NET will cache a prior version of them
until the application is reset.

This should also be done for any other files in the project that might be
changing on the fly.

Hope this helps...

Bruce Barker · Aug 1, 2005

usually ccs files (*.css) are not served up by asp.net but by IIS directly.
IIS will pass the modified date on a get/head request.

for link files like *.ccs, the browser usually caches them by browser
session (until you exit the browser). with a new session, the browser does a
head request to see if the file has been modified, if so it reloads.
generally all you need to is hit the refresh button in the browser to reload
the css/image files, but IE is a little buggy. somestimes you have to exit
the browser and restart.

if your css files are actually *.aspx pages, asp.net should do the correct
caching for you if you are editing the aspx file.

-- bruce (sqlwork.com)

Frankie · Aug 1, 2005

Since my last post in this thread I stopped and started the Web site in IIS
Manager. Problem disappeared (I could no longer duplicate it).

Bruce - FWIW: my css files are actually css files (not aspx pages).

As Brad noted, restarting the ASP.NET Web application is necessary
sometimes; and in my case the files were already NOT included in the
project). In my troubleshooting efforts I had been restarting the ASP.NET
App by saving a change to Web.config. But apparently that's not the same as
Stopping and Starting the IIS Web site.

The only thing unusual about my aspx pages is that I'm injecting the [path
to the css file] into the <HEAD> at runtime. I'm not injecting CSS Classes -
just the path to the css file. Doing that was fine during development and
for a long time in production, and now it's fine again - it's just that
*something* mysterious (to me anyway) happened and Stopping and Starting the
Web site in IIS aparently cleared it up - even though recycling the
Application Pool did not clear it up.

While I can no longer reproduce the issue, I still don't know what caused
the issue in the first place. I'd hate to let it go at this. Any suggestions
for followup, or would I really need to wait and see if it happens again?

-F

Joerg Jooss · Aug 2, 2005

Frankie wrote:

[...]

While I can no longer reproduce the issue, I still don't know what
caused the issue in the first place. I'd hate to let it go at this.
Any suggestions for followup, or would I really need to wait and see
if it happens again?

During development you could mark your files non-cacheable -- this will
ensure you always run with your latest CSS.

Cheers,

Automatic Page Content Expiration	2	Aug 1, 2005
IIS Content expiration header and ASP.NET	0	Mar 30, 2006
Cookie name and expiration	1	Nov 25, 2009
Visual Studio Ignores IIS Content Expiration	0	Mar 7, 2005
Enable Content Expiration: Immediate	0	May 23, 2005
Controling cache expiration	2	Mar 28, 2005
Question about multiple metadata files to one file	0	Feb 14, 2022
cookie expiration	0	Sep 5, 2006

Content Expiration Question

Frankie

Frankie

Guest

Bruce Barker

Frankie

Joerg Jooss

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads