When doing updates to accounts in CRM 4.0, the preview does not update unless we clear the client cache. When requesting the preview (which happens when you click the little arrow shown in the screenshot) with URL shown below, the headers shown below are returned.
GET http://crmdev/DevOrg/_grid/preview.aspx?type=1&id={755E4F74-007D-E011-A3BC-005056B6001D} HTTP/1.1
As can be seen from the headers, there is no expiration date/time on the cache.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 1006
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Persistent-Auth: false
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate <token removed>
Date: Tue, 19 Jul 2011 13:35:10 GMT
Setting the cache to expire using the method described in the following link has no effect. http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache
Does anyone have a supported fix for Dynamics CRM 4.0 regarding the caching of the preview.aspx page? Almost all other examined pages in CRM returns 'Cache-Control: no-cache', so seemingly this file overrides the output header.
ADDITIONAL INFO ADDED
This behavior only affects IE9. Either IE9 is handling the caching unlike IE8 and before or IE9 is not allowing the corss tab/popup cache invalidation.
Suggested hotfix (unsupported): Replace preview.aspx with a custom aspx file that uses the original renamed file and has manual control over the cache header. Setting the cache-header to 'no-cache' solves this issue in IE9. We have opted out of this solution as it is unsupported, but it has been tested ok and requires no altering of aspx-content, only "rerouting".
This behavior only affects IE9. Either IE9 is handling the caching unlike IE8 and before or IE9 is not allowing the cross tab/popup cache invalidation.
Suggested hotfix (unsupported): Replace preview.aspx with a custom aspx file that uses the original renamed file and has manual control over the cache header. Setting the cache-header to 'no-cache' solves this issue in IE9. We have opted out of this solution as it is unsupported, but it has been tested ok and requires no altering of aspx-content, only "rerouting".
Related
I have implemented caching on my webserver for static files like images. I've tried setting response headers such as:
Cache-Control: public, max-age=864000
Expires: Mon, 21 Aug 2018 14:00:00 GMT
This will at least cache the files for one day. But using the Developer Tools, I can see the requests still being fetched without caching.
The browser seems to send request headers like:
Cache-Control: no-cache
Even though I explicitly instruct it from my webserver not to do that.
In most browsers, when you have Developer Tools open, the browser actually sends Cache-Control: no-cache in the request as a supposedly "useful feature" since you are probably debugging.
By default this feature is enabled. In FireFox this feature can be found listed below the 'Advanced settings' in the settings-menu (use the gear icon) as: Disable HTTP Cache (when toolbox is open)
Uncheck that feature, and caching should work.
When you are developing a web application using Visual Studio (e.g. ASP.net MVC) and you use Chrome for running your application, Chrome will always send header Cache-Control: no-cache. No matter whether you Disable HTTP Cache. Also closing the Developer Tools does not help.
What does help: Use another browser for debugging or start a new instance of Chrome.
I'm trying to download an excel file (generated dynamically using C#\ASP.NET) and I get the IE10 View Downloads dialog when I click "Open" it says "abc.xls couldn't be downloaded" error but after clicking "Retry" it opens the .xls file properly in the second try.
When I test this in Firefox or Chrome it works fine.
I think this may explain the strange behaviour:
"Content-Length and Transfer-Encoding Validation in the IE10 Download Manager"
It seems that IE9 beta had introduced content-length and transfer-encoding validation when downloading files, but found it was too problematic since many servers didn't send proper values for these downloads that are processed through code. Apparently they turned it back on in IE10 however and just hoped for the best.
I'd wager that accurate values being sent when the download is started should clear up this problem. Of course, it shouldn't have been a problem to begin with... ai yi yi.
[Edit]
Turns out this problem was related (for me at least) with using Response.Close() and/or Response.End() in code. This article explains why you shouldn't use these 2 methods, and why HttpApplication.CompleteRequest is the method of choice. Changing our Response.End() and Response.Close() instances to HttpApplication.CompleteRequest solved our IE10 download issues. Like magic. Apparently MSDN now discourages use of these 2 methods (despite years of MSDN code examples containing them), and now advocates use of HttpApplication.CompleteRequest instead.
We were always at war with Eurasia...
[/Edit]
I was getting a similar behavior -
After fighting this issue for about 12 hours what worked for me:
Changing response header from
Content-Type: application/application/vnd.ms-excel
To
Content-Type: application/octet-stream
Note that I had another an unmentioned symptom: I was setting
Content-Disposition: attachment; filename="Inventory_10-10-2013.xls"
Despite that setting IE used the file name from the URL (so it said "getInventory couldn't be downloaded" - and it saved the wrongly named file in the downloads folder!).
When I changed the 'Content-Type' IE started honoring the file name from the header.
For the record here are all the response headers that I'm setting:
HTTP/1.1 200 OK
Pragma: Public
Expires: Fri, 11 Oct 2013 16:33:38 GMT
Cache-Control: max-age=1
Content-Disposition: attachment; filename="Inventory_10-10-2013.xls"
Content-Transfer-Encoding: BINARY
Set-Cookie: fileDownload=true; path=/
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 7680
Date: Thu, 10 Oct 2013 16:33:38 GMT
I have the following action method:
[HttpGet, Authorize, OutputCache(Duration = 60, VaryByHeader = "Cookie", Location = OutputCacheLocation.Any)]
public ActionResult Index()
But when I make a request, these are the headers issued:
Cache-Control: private, max-age=60, s-maxage=0
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Fri, 22 Jun 2012 09:56:32 GMT
Last-Modified: Fri, 22 Jun 2012 09:55:32 GMT
Vary: Accept-Encoding
Why isn't it including the Cookie header in the Vary?
I've tried many variations of the OutputCache settings but to no avail :(
I hate IIS almost as much as I hate ASP.NET.
http://blogs.msdn.com/b/chaun/archive/2009/10/01/iis-compression-overwrites-the-vary-header-average-rating-0-ratings.aspx
So the response is included in the linked by Andrew Bullock url "page file name", aka "iis compression overwrites the vary header".
But since December 2013 a hotfix is available (found on Andrew Bullock link). As usual, this hotfix may be included in regular patches, so make sure you still need it before applying it.
And as it is "best practice" to explicitly supply information from links rather than only supplying the link (in case the page goes down), here is an abstract :
IIS dynamic compression overwrites the Vary header. This seems to apply to IIS from version 5 to version 8 included (when cumulating information from msdn blog and from msdn kb). Either disable IIS dynamic compression, or try applying the hotfix available at http://support.microsoft.com/kb/2877816/en-us if needed. (This issue may be fixed by regular patches on windows 8.1/2012 R2 series. The hotfix is available starting from IIS 7, personally tested on win7 sp1, not yet on my servers.)
In my specific case, I had also another issue : asp.net was not emitting any Vary header (compression enabled or not) with outputCache location set to Client. Setting it to Downstream "solved" this additional issue. But of course, this has the side-effect of changing Cache-Control from private to public. (Now cacheable on proxy instead of just on client browser.)
I have a rendered HTML page that I am exporting to MS Word and downloading on a button click.
Here is the code snippet in the button click.
` Me.EnableViewState = False
Response.ContentType = "application/vnd.ms-word"
Response.AddHeader("Content-Disposition", "attachments;filename=XXXXXXX.doc")
Response.Buffer = True
Response.BufferOutput = True`
The functionality works perfectly well in Firefox & IE when I checked in system testing environment (locally). However when it was moved on to the hosting server (production environment) the functionality is not working in IE but is still working perfectly in Firefox.
I am not sure on where to check for the exact issue. Could it be a caching related problem?
In IE it is just not opening the download window which we will obtain when the rendered HTML content type is changed and the response stream is flushed. No exception is thrown.
I received the following response header:
HTTP/1.0 200 OK
Cache-Control: private
Content-Length: 15189
Content-Type: application/vnd.ms-word;
charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 2.0.50727
Content-Disposition: attachments;filename=NewAccountForm.doc X-Powered-By: ASP.NET
Date: Fri, 18 Mar 2011 10:18:07 GMT X-Cache: MISS from Gateway X-Cache-Lookup: MISS from Gateway:808 Via: 1.0 Gateway (squid/3.0.STABLE10) Proxy-Connection: keep-alive
Is your hosted environment adding http headers? IIS could easily be configured to add headers that are messing up what you want to send out. It's actually quite common, and could be the issue. You'll need to determine this for sure, so here's a suggestion for investigating:
Try using a WebClient class and look at the Response headers.
Edit - updated
I just noticed - did you remember to put
Response.Clear();
before adding headers? It may not be the hosting environment at all. However, given that it works locally and not at your hosting environment, and assming that it is the same code, it still looks to me like something is different about the hosted environment, and the most logical option would be the headers.
I set Response.Charset = "" and always do Response.Flush(), Response.End(), and Response.Close() after I export the HTML.
This is just making me angry. I can't figure out why all the resources in my page are being requested EVERY single time.
E.g. my site.css returns the following headers (using fiddler):
HTTP/1.1 200 OK
Server: ASP.NET Development Server/9.0.0.0
Date: Mon, 29 Nov 2010 17:36:21 GMT
X-AspNet-Version: 2.0.50727
Content-Length: 9093
Cache-Control: public, max-age=2592000
Expires: Wed, 29 Dec 2010 17:36:21 GMT
Last-Modified: Mon, 08 Nov 2010 17:20:16 GMT
Content-Type: text/css
Connection: Close
But every time I hit refresh I see all the resources (css,js,images) getting re-requested. I have control over the headers returned for any and all of these resources, but I haven't figured it out yet.
I have even debugged my ASP.NET app and the HttpModule is definitely being asked for the resources again.
Can someone give me an idea of what to do?
EDIT:
Ok, I removed must-revalidate, proxy-revalidate from the headers and that is getting me closer to where I want to be, now when I press back it still requests my css/js files when I press back.
Is there anything more I can do to avoid this?
The following links might be of help to you.
Differences in reload behavior between FF and IE
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
In a nutshell, your caching behavior is going to be determined by the headers and the browser you are using.
What browser are you using for testing? The back button is also handled differently.
Back Button (Browser Behavior)
And, finally, a breakdown of f5/ctrl f5, click, shift click, etc behavior between browsers:
What requests do browsers' "F5" and "Ctrl + F5" refreshes generate?
If you are handling the requests in your own module - which seems to be the case - and the request contains an If-Modified-Since header, you can use that to determine whether to respond with a 200 and sending the whole resource again, or just send a 304 and skip sending the js/css/etc contents.
Other than that, expect browsers to re-query resources on hitting F5 / Refresh. It is just that you may skip sending the whole js/css/etc and return a 304 if everything is OK.
Other than that, #Chris's answer covers pretty much everything else.
What are the request headers you see when you hit back?