How would one configurably set http-headers to cache files in IIS >= 6?
Example:
*.cache.* => cache nearly forever
*.nocache.* => never cache
An example framework using this naming would be the GWT framework.
I think you're referring to setting the cache-control header.
See here http://support.microsoft.com/kb/247404
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/23ea6f24-4b44-4fa0-a275-a1b907e1afb6.mspx?mfr=true
Explains the different methods of caching data in IIS.
Related
I'm testing Varnish cache integration with Shopware6.
During Settings > Caches & Indexes > Clear caches Varnish is not involved at all.
Result: cache in Varnish is not purged and store continue to serve pages cached in Varnish.
Am I missing something or is Shopware lacking of this part of integration?
did you configure shopware, and set the path for the varnish?
https://developer.shopware.com/docs/guides/hosting/infrastructure/reverse-http-cache#configure-shopware
if shopware dosen't know the proxy, i't can't be purged.
I am using two application load balancers that are routing requests to 4 backend varnish servers. I got answers to configure the PHP file to purge the cache but I have no idea where to put it and how to execute.
For which type of PHP application are you trying to configure cache purging?
A custom application?
WordPress?
Drupal?
Magento?
Some other CMS or framework?
If you're using an existing platform, CMS, or framework, the documentation will probably state how to configure purging.
Varnish Configuration
Of course, the Varnish VCL code should also be tuned to process purges.
You can find more information about purging (and banning) in Varnish on http://varnish-cache.org/docs/6.0/users-guide/purging.html
Here are the questions you should ask yourself regarding purging. Maybe the documentation of your CMS or framework will answer these as well?
Are you trying to purge individual URLs?
Does your code have pattern matching in play to invalidate multiple URLs at once (uses bans in VCL)
If pattern matching is used, are you sending the invalidation pattern via an HTTP request header?
Does your invalidation code use the URL to identify objects in cache, or does it rely on tagged content?
Are you restricting access to the purging mechanism based on IP address or subnet. If so, please configure an ACL in VCL.
Many WordPress plugins rely on individual URL purging. Other WordPress plugins use bans through request header patterns.
Drupal uses bans, but has a system in place that tags content. The ban patterns don't match URLs, but tags.
Magento uses bans.
Conclusion
If you use a CMS or framework, the purging strategy is set in advance. It's just a matter of configuring your app and making sure the VCL can handle it.
If you have custom code, you have a choice, and you can implement purging or banning.
Please have a look at the user guide section about purging I mentioned above. It should help you understand the underlying mechanism.
I want to follow Google's directive in terms of cache headers for images, scripts and styles.
After reading symfony's documentation about http cache, I decided to install FOSHttpCacheBundle. The I set up rules for path like ^/Resources/ or ^/css/. I then fail to see it the proper headers for my images using Chrome's console.
Alternatively, I have read that, since my server is handling the resource, this is not Symfony that deals with this matter (yet I read in the doc that Symfony Proxy was good for shared-hosting servers, which is what I have).
So should I just add lines to my .htaccess as explained in here, or am I simply misusing FOSHttpCacheBundle? (Or both.)
Static files (including javascript files, CSS stylesheets, images, fonts...) are served directly by the web server. As the PHP module is not even loaded for such files, you must configure the server to set proper HTTP headers. You can do it using a .htaccess file if you use Apache but doing it directly in httpd.conf/apache2.conf/vhost conf (depending of your configuration) will be better from a performance point of view.
If you also want want to set HTTP cache headers for dynamic content (HTML generated by Symfony...), then you must use FosHttpCache or any other method provided by Symfonny such as the #Cache annotation.
Have some strange behaviour regarding output caching in an ASP.NET 4 application on IIS 7.5. I've been able to repeat the problem simply on other empty setups, I'm certain this is a bug, but unsure how to report it to Microsoft.
A site in IIS responds to more than 1 domain, the .NET application examins the hostname, and produces content accordingly. For example, it may print the name of the request URL in a blank page. Eg, www.first-domain.com, and www.second-domain.com
The web.config has the appropriate caching, urlCompression, and httpCompression all turned OFF under the system.webServer node.
The aspx page sets the cache-control header for public, with either a future date for expires, or a max-age value.
Visiting www.first-domain.com outputs the page that successfully writes 'www.first-domain.com'.
However, visiting www.second-domain.com outputs a page that writes 'www.first-domain.com'.
Examining the failed-request-traces, System.Web.Caching.OutputCacheModule has found the cached output (even though the .config files have turned the function off), the cache has matched even though the request URL hostname are different, and thus the second request will output the results of the first request to the different domain for as long as the max-age/expiry was set for, before the correct page for the second-domain will appear.
Either setting cache-control to private, or removing the 'OutputCache' module in the web.config solves the problem, while maintaining the correct cache-control headers sent to the browser, but obviously, I can't take advantage of kernel caching when I need it.
I can't find any MSDN documentation on how the OutputCacheModule is configured.
Has anyone else experienced this issue, how can I go about enabling kernel caching and let it take into account URL Hostname (without separating the application to different sites in IIS).
Thanks.
Update:
Adding SetSlidingExpiration has no effect, as the kernal cache still caches the output regardless of the request hostname. The only scenario now is to either disable output caching, or run a duplicate instance of the app on each domain it will run - considering the drop in server performance this would result in vs. the increase of performance gained in using output caching, we decided to disable output caching for this app.
No answer has been provided after 9 months, and no solution has been found, only a workaround, perhaps this will be fixed in the next version of IIS greater than 7.5...
--
Adding SetSlidingExpiration has no effect, as the kernal cache still caches the output regardless of the request hostname. The only scenario now is to either disable output caching, or run a duplicate instance of the app on each domain it will run - considering the drop in server performance this would result in vs. the increase of performance gained in using output caching, we decided to disable output caching for this app.
I was having a very similar problem and no solutions here helped me.
TLDR: Forcefully removing the OutputCache module on the Web.config was the only solution I found.
My scenario was a little bit different.
I have CORS set up in Application_BeginRequest, answering Access-Control-Allow-Origin for specific hosts that call me (setting it to * has not been reliable).
My Controller also sets Cache-control: public for it's responses.
What I found
Whenever I set Cache-control: public, IIS forcefully caches the response. Breakpoints on either Application_BeginRequest or my Controller were never hit a second time.
Disabling output and kernel caching via IIS Manager as seen below would have me hitting the Application_BeginRequest breakpoints, but never got me into the Controller. Something was still caching responses.
This article suggested removing the OutputCache module from IIS would help.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="OutputCache" />
</modules>
</system.webServer>
Doing so allowed me to hit my Controller, finally.
What would help even more
If someone from MS or not could shine a light whether there is a way to change this behavior. OutputCache could be useful in some parts of an application and unnecessary in others.
Beware
Maybe I'm(we're?) solving the wrong problem here.
Maybe IIS was taking over caching in this scenario because it should. Maybe proxies along the way between my server and the user would behave just like that in that exact scenario, and if that's the case then working around this on IIS is wrong. I'll have to figure that out and maybe you should too.
I have similar problem. I use custom url rewriter. I have pages example.com/articles and example.com/art-ANY_ID.html. Both url map to articles.aspx (in second example as articles.aspx?id=ANY_ID). It worked fine with ASP.NET 2.0 and Classic pipeline mode. After we have changed it to ASP.NET 4 and integrated mode, we have got strange behaviour: both url return identically output. It was any page like example.com/art-ANY_ID.html.
Now we removed <add extension=".html" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" /> from section <caching enabled="true" enableKernelCache="true"> and it fine works. I not understand why http.sys cache it.
Have you find any explanations?
Is a http header that I can set in IIS that will essentially tell the users browser that url
"/something/img.gif"
and url
"/SomeThing/IMG.gif"
are in fact the same thing and that the browser should NOT re-download that resource? I'm running into cache issues where some urls are cased differently, and so users browsers are re-downloading the resource.
URL's are by definition case-sensitive. The problem is that by default, Windows filesystems are not case-sensitive. This is why IIS added that hack, but normally you should not use it. There's probably nothing you can do about the caching issues, because browsers follow the standard and assume different case is a different file. My suggestion would be to fix your website such that it always uses the same case to request things.