I recently changed from squishit.framework to the built in bundling with asp.net mvc and am seeing the expires headers of the bundles (js and css) is set to expire immediately.
How to set the expires headers for these? I thought they were meant to be set for 1 year automatically?
Thanks
EDIT: Exipres headers are being set correctly, my fault. The problem is that when I refresh the page I get status 200 everytime. This should be 304. Only when I do a hard refresh the content should be loaded again.
If I compare this with squishit.framework, there is a file added to the file system from where I can manually set the expires headers in IIS. After refreshing that, I do get a http 304 not modified until I do a hard refresh (ctrl+F5)
Related
Jenkins was working fine on Firefox until a couple of weeks back.
http://www.sub.domain.com:8080
Then I think there was a Firefox update and by default it was redirecting to
https://www.sub.domain.com:8080
There was no way I could force it to http.
So I went on Chrome and it worked there until this morning when I got the Chrome 77 update.
Same issue all over again.
Then I loaded it up on IE. It works fine. I am able to use
http://www.sub.domain.com:8080
I checked with the admin if they are redirecting all traffic to https but that's not the case. What's happening here? Any browser change that I am not aware of? Any Jenkins config change that I should be using?
Did you check the HSTS cache in chrome? Go to chrome://net-internals/#hsts
Query the HSTS cache there. If there is a result you can clear it using the delete option on that page.
Another thing to check is if your using the Jenkins HSTS filter plugin "which adds a response header indicating that HTTP Strict Transport Security (HSTS) response headers should be sent." See https://wiki.jenkins.io/display/JENKINS/HSTS+Filter+Plugin
I am running Apache 2.4.18 on Ubuntu (single server machine). I didn't make any changes to the default settings as far as cache headers are concerned (no cache-related change to /etc/apache2/apached2.conf, no .htaccess files). My understanding is that apache's default behavior is to use ETag's, with the desired behavior of returning a 304 if the client already has a matching file, or a 200 (plus the new file) if it does not.
This is not what I see.
On iOS/Safari, when I update files on the server, my client behaves as if it has a mix of old and new files. This can be resolved by clearing web data in Safari and reloading the page, so it does seem to be a caching issue. I read that iOS/Safari is (or at least was, in earlier versions?) different in its respect for ETag headers. But it wasn't clear to me how to fix this.
On Chrome in Windows, the file is always served (i.e., response 200, not 304) even when the file hasn't changed since the last request, even though I can see the use of ETag in the headers.
Can someone share their apache 2.4 settings to get the desired behavior I describe above, on both iOS and Chrome?
(Here is another question that asks the same thing about the Chrome part: Apache + Etags -> returns 200 and send content instead of 304)
I think the answer to my question is that caching works differently, at least in Chrome, when you are using the file:// protocol to test locally vs. the http:// protocol.
I updated my project MVC version to 5 and now iFrame does not load, I get this error:
Load denied by X-Frame-Options: www.blahblah.com does not permit cross-origin framing.
I noticed that for some reason now the X-Frame-Options header has SAMEORIGIN filled which does not allow the iframe to load a page from a different domain. This is a problem for me as I develop both the containing and inheriting page. I tried everything in IIS to change this header to no avail.
Anyone encountered this yet?
I finally found the answer. Starting with MVC 5 Microsoft decided to set SAMEORIGIN in there by default. The best way I found to turn this tag off is by writing the following in the Global.asax.cs
protected void Application_Start()
{
//Bundles and stuff are here
AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}
Assuming your IFrame content is being served by your MVC app...
You might need to include a response header that permits cross origin requests:
Access-Control-Allow-Origin: *
I'm back on a MVC app where I thought that output caching was working as expected. However, while revisiting it, I see that the OutputCache attribute I use has no effect (Duration is set to a high value). Whether I add it or not, the breakpoint in my action is always hit and Firebug shows me a 200 OK on the requested page in each case.
In a more complex action where I use VaryByCustom, the GetVaryByCustomString method in global.asax is never called. I know that it was called in the past since I was able to debug there but now it's not.
I wonder what I did to break this... Any idea?
(in order to not only test localhost, I use a dyndns.org address so that it's a valid external URL. I also use IIS).
Update: when I use the localhost URL, targetting the same url does not enter the action code again. Hitting F5 does. When using the internet URL it always visits the action code.
Update 2: Fiddler is showing this in the response headers:
200 OK
Cache:
Cache-Control: public, no-cache="Set-Cookie", max-age=86400
Date: Mon, 16 Jul 2012 19:38:46 GMT
Expires: Tue, 17 Jul 2012 19:38:46 GMT
Vary: *
Expires = Date + 24h each time I request the same url, which shows that a new page is served each time. Also I should get 200 the first time and 304 thereafter.
Just discovered the culprit, which is contextual to my application:
If I remove the 51degrees.mobi nuget package from my app, it just works again. Put it back (even without using its features) and caching is dead. Well, in fact there are 2 cases:
If you just add the package, GetVaryByCustomString is never called. The action method is called once correctly and then is served from the cache.
If you add the package AND you also use a CompressFilter attribute, then GetVaryByCustomString is never called AND the action method is always called (no page served from the cache).
I posted to their forums to report this issue.
Update: these issues appear starting with 51degrees version 2.1.4.9. I notice that this is the first version using Microsoft.Web.Infrastructure, in case this is relevant...
Update 2: they found the cause of this issue and it will be fixed.
I have a website with some css and images.
I pushed some changes about the css and images to live.
I open IE/Firefox and type the URL to my website and hit return.
Then nothing is updated. I saw the IE/FF is not even try to ask for update, so there is no 304 returned.
I have to F5 fresh to get new content, but my users may not do this.
Does anybody know what to do?
Thanks
What is your HTTP server? You'll need to have it set the Cache-Control: no-cache HTTP header to disable caching at all your users.