Migrating my website to a secure server, a frame is being blocked by browsers because of a security issue which doesn't happen on my existing website, which is hosted on an http server. [Google Chrome Developer Console screen shot][1] [1]: https://i.stack.imgur.com/wQkpr.jpg
The page should load a calendar, but it does not do so.
I'm not a coding expert, and don't know how to resolve this. The issue happens when loading this page:
Page which generates DOMException
However, the site under development is hosted on a non-public server. In order to access it, the hosts file on a Windows platform would need to have this code added: 199.168.187.45 mauitradewinds.com www.mauitradewinds.com secure.mauitradewinds.com m.mauitradewinds.com
Without adding that code to the hosts file, a browser would be redirected to my existing http site, which is not where the issue is happening.
I'd be grateful for guidance on how to eliminate this frame blocking.
My guess is you have a protocol conflict between your iframe and your main page.
Your main page is accessing through http and the iframe through https.
Your existing website most probably has a redirect from http to https which is why the issue is not happening on the existing site.
A web developer solved this by observing that adding www to the URL would prevent the DOMException, and allow page frame content to load.
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 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)
It seems that in Webkit-based browsers (Chrome and Safari) when a Post/Redirect/Get is performed on the server, the entire page (html + images + css, etc.) is redownloaded. It appears the same as if you reloaded the page.
There's been a question (and somewhat of a solution) posted in the Google Chrome Help: http://www.google.com/support/forum/p/Chrome/thread?tid=72bf3773f7e66d68&hl=en
Does anyone have a more elegant way of doing this? I'm working with ASP.NET MVC and would prefer to not write a custom Redirect result that returns Javascript or the actual page based on the UserAgent.
Should I just hope and wait that Webkit will change its behavior?
This is a bug. The only "workaround" I've seen untill now is to use a Refresh header instead of a Location header to do the redirecting. This is far from ideal.
Bug 38690 - Submitting a POST that leads to a server redirect causes all cached items to redownload
Also, this question is a duplicate of "Full page reload on Post/Redirect/Get ignoring cache control".
Try setting Cache-Control: public header.
I have a controller in MVC serving up images from a database.
EDIT: This still happens if I serve up a file over completely standard means in MVC.
Every time I request my image, Google Chrome also searches for my favicon.ico.
To avoid unnecessary discussions about other things "I should also care about" let us assume I do not care for caching whatsoever in this example and I shall always return HTTP response 200 with the file.
In my controller I return the following:
return File(fileBytes, contentType);
After inspecting Fiddler 2, the following response is generated:
HTTP/1.1 200 OK
Cache-Control: public
Content-Type: image/gif
ETag: oYu19wKo+KEHkyxZQ2WXAA==
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 1.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Tue, 16 Jun 2009 18:48:45 GMT
Content-Length: 29344
By comparison, this is the response in Fiddler from Google when I request (for the first time) the Google logo:
HTTP/1.1 200 OK
Content-Type: image/gif
Last-Modified: Wed, 07 Jun 2006 19:42:34 GMT
Date: Tue, 16 Jun 2009 18:50:54 GMT
Expires: Wed, 16 Jun 2010 18:50:54 GMT
Cache-Control: public, max-age=31536000
Server: gws
Content-Length: 8706
Age: 2
However, in Chrome after getting my image Chrome attempts to find my favicon.ico. It does not try this after requesting the Google logo.
Any ideas why this might be happening? From my understanding on HTML, the answer must be in the response header because surely that is all the client has to go on? Please correct me!
EDIT 2: It seems a lot of people have completely misunderstood the problem. The problem is not the lack of a favicon and the erroring requests in MVC - it's the problem of requesting a favicon when only an image is being loaded, with a content type of "IMAGE/JPEG", as opposed to a webpage with a content type of "TEXT/HTML"!!
This has nothing to do with MVC. I am using webforms with a custom built log service and I stumbled upon this post wondering why I had continuous 'File does not exist' errors in my logs. This is locally on my development machine, I have no favicon.ico files in my projects, and I have tried IE, Firefox and Google trying to see which browser is the guilty party.
Every request from Google Chrome to my apps makes a request for a favicon.ico. I had to start logging browser locally to determine that it was in fact googles browser that is the culprit. I'd contact google if it bothers you. I just wanted to make sure it wasn't some new trojan infecting my chrome.
The actual answer: It's a known, verified bug. *(recently fixed!... maybe?)
Looks like a known, longstanding issue with Chrome:
http://crbug.com/39402
If you want it fixed sooner, star the issue. More people starring the issue will likely increase its priority and possibly get it fixed faster.
****UPDATE 1***: As of May 15 of this year (2013)--four years after this question was asked--it looks like the issue has been fixed in version 29:
http://crbug.com/39402#c47
Feel free to undo all your hacks and workarounds. :]
****UPDATE 2 (2015-01)***: This is apparently still an issue for some users, according to the same issue link. :/
Do you have a favicon? If not, perhaps that's why Chrome is attempting to find it every time for your website. For google it already has the favicon cached.
one thing you could do is have MVC ignore any request for *.ico so that you don't get any exceptions while debugging.
Should be something like this:
routes.MapRoute("ignore-favicon", "{*path}", null, new {path = ".*/favicon\\.ico"});
That URL pattern matches everything, but then we constrain it to only match anything ending in favicon.ico. (I haven't tested this)
I ran into this problem a while back and got around it by ignoring the specific route by adding
routes.IgnoreRoute("{*favicon}", new { favicon = ".*/favicon\\.ico" });
into the RegisterRoutes method in Global.asax.
It appears for me that Chrome requests a favicon for its own tabs - I kept getting 404s (because my favicon is somwhere else and my pages know it) till I did some tests and realized it was Chrome making direct requests to the favicon file. No real fix except making a rewrite to the real file I guess
You can add something like this within your web.config file to make sure that the favicon.ico is cached on the client and is not being requested every time.
<location path="favicon.ico">
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="public, max-age=31536000" />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
You can/should do the same for any images / .js and css files
You should set the Expires header to tell the browser how long it should use its local copy.
If you check your project setting it says default icon somewhere. Remove that?
Chrome browser could work with Google site in another way than with any other site, so, at first, I would recommend to check if it looks for favicon.ico every time somewhere else, for example, on StackOverflow.
I would also check if Firefox does the same with your site. I think favicon.ico should be requested only one time per browser run even if it isn't present on site. This could be bug in Chrome version you use.
This SO question/answer explains how to serve the Favicon to the browser by using routes.
Its important to put in an ICON link into your masterpage or some browsers will try to find favicon.ico for all directories and not just globally once per done.
<link rel="SHORTCUT ICON" href="<%= Url.Content("~/content/images/rr-favicon.ico") %>"/>
It seems google toolbar is the guilty party judging by my logs (and IE6 of course). They both will make requests for directories other than the root
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/4.0 (compatible; GoogleToolbar 6.2.1910.1554; Windows 6.0; MSIE 8.0.6001.18828)