B
Brian
I have an ASP.NET 1.1 app that rewrites URL's. Rewriting a path to an
..aspx file that does not exist throws a nasty server-500 exception, not
a 404. One thought I had was to Server.MapPath the URL I'm about to
pass to Context.RewritePath and check it with System.IO.File.Exists. My
concern is the expense of touching the filesystem like this for each
and every request I get - is this a bad idea?
A similar question I have is forcing client-reloads of .css, .js, &
image files that have changed since the last time a client visited our
site. In a previous life we wrapped URL's like these in an object that
appended the timestamp from the file:
....src="path/styles.css"...
Would result in
....src="path/styles.css?200604101442"...
Where the text after the ? was the file's timestamp and would be enough
to cause the browser to fetch it over the wire instead of use its
cache. But again, I'd be touching the filesystem _a lot_ to get this
information - will that scale? Or, is there a better way to do this?
Thanks everyone!
-Brian
..aspx file that does not exist throws a nasty server-500 exception, not
a 404. One thought I had was to Server.MapPath the URL I'm about to
pass to Context.RewritePath and check it with System.IO.File.Exists. My
concern is the expense of touching the filesystem like this for each
and every request I get - is this a bad idea?
A similar question I have is forcing client-reloads of .css, .js, &
image files that have changed since the last time a client visited our
site. In a previous life we wrapped URL's like these in an object that
appended the timestamp from the file:
....src="path/styles.css"...
Would result in
....src="path/styles.css?200604101442"...
Where the text after the ? was the file's timestamp and would be enough
to cause the browser to fetch it over the wire instead of use its
cache. But again, I'd be touching the filesystem _a lot_ to get this
information - will that scale? Or, is there a better way to do this?
Thanks everyone!
-Brian