UtcSetLastModified exception thrown by Jonathan Greensted

In this particular case where it is about deployment, the problem is probably that you are compressing your data with a nonUTC aware compression tool. We had the same problem, and after we switched to 7zip it went away.

However, it is still a bug in itself. If you store a file on a shared server, and two webservers have a tiny time sync issue, and you setup the cache header for the file using fileinfo.LastWriteTimeUtc then you might also get a problem. It should be fixed, so that tiny values into the future are accepted (10min?).

Here's an interesting oddity. I saw this happen in the AjaxPro code. The have the following:

     DateTime now = DateTime.Now;
     DateTime lastMod = new DateTime(now.Year, now.Month, now.Day, now.Hour, now.Minute, now.Second);
    
     context.Response.AddHeader("Content-Type", "application/x-javascript");
     context.Response.ContentEncoding = System.Text.Encoding.UTF8;
     context.Response.Cache.SetCacheability(System.Web.HttpCacheability.Public);
     context.Response.Cache.SetETag(etag);
     context.Response.Cache.SetLastModified(lastMod);

And I will get the same exception trace in the log:

    Stack trace:    at System.Web.HttpCachePolicy.UtcSetLastModified(DateTime utcDate)
at System.Web.HttpCachePolicy.SetLastModified(DateTime date)
at Ajax.MultiTypeJavaScriptHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

If the code gets DateTime.Now, lops off everything after second, how does UtcSetLastModified find this DateTime to be in the future, when I presume that it makes a similar call to get the current DateTime to compare. The one thing to note, is that this happened on Sunday Nov 1st, 2009 between Midnight and 1am, in the US. Now I know that Daylight Saving Time is not suppose to happen until 2am, but it feels like that is involved some how.

Thanks for any thoughts on the matter.

This still happens when you deploy on a "behind clock" server.
Eg. Working on Romania and deploying on a US server is still causing the same stuppid error!
ASP.NET 2.0 - .NET 3.5 - Windows Server 2008 IIS7 / Windows Server 2003 IIS6

The Microsoft Sub-status is now "Working on solution"

The cause of the bug is that HttpCachePolicy's UtcSetLastModified(...) method has a validation check so that the DateTime passed in is not in the future. This value is used in generating the HTTP response header "Last-Modified", so it's important that the value not be in the future.

The change in system time can cause this problem because we use the last write time of the file in the static file handler to set the last modified time. The fix that we decided to do what to check and see if the file's last write time is in the future, and if so, override it and use the current time. It was deemed the least intrusive compromise, since we really can't change the behavior of the UtcSetLastModified method.

The Microsoft Sub-status is now "Working on solution"

Thank you for submitting this issue - we are currently investigating a solution. Thanks, Web Platform and Tools Team.

Jonathan,

Nice catch. Looks like a real bug on first look.
But here is a problem - file modification time will be sent to client as Last-Modified HTTP header and file will be cached in user cache with this time.
Then requesting file at second time - browser will use date from cache and set If-Modified-Since: conditional get header in HTTP request expecting to receive 302 Not Modified response or content of new file.

Here is a problem. Once user will receive file with incorrect date (in far-far future) - If-Modified-Since requests will be unable to detect if file was changed and use stale data.
This is probably a reason why Microsoft throws an exception in this situation. This is absolutely legit reason for this.

But now take a look on this from other side - if due to some problems time/date on server were changed (BIOS battery failed) - this will result on service failure.
Or even more tricky issue - file stored on FAT disk - modification time on FAT disk has 2 seconds precision and rounded UP!! While I've found that HttpCachePolicy.UtcSetLastModified check time with 1 second!

This is clearly a big issue and must be fixed.
Proposed fix is to check all file date/times in StaticFileHandler.ProcessRequestInternal (and similar classes) and use Min(DateTime.Now, FileTime) for last-modified time. In worth case - conditional get will always report that file modified. But service failure will be prevented.

Jonathan, Thanks again for your report ;-)
I hope Microsoft will fix this, if not done already