This error keeps on appearing. How to remove this? My site is an https and the content of the iframe is also coming from an https source, I don't know what seems to be the problem?
// edited:
this is the detailed error that appears. and yes, I am using IE6.
There are nonsecure items in either your page or in the iFramed page. Look at the source code for any URL that does not begin with https://.
You will have to look very closely at all your resource references.
1) Make sure that it's the <iframe> that is causing your problem. Do as #JonathonReinhart suggested and comment it out so that you can ascertain that your issue is from there. (Edit: never mind, it appears that the <iframe> is indeed your issue)
2) Browsers are very sensitive to iframes because they can access content that is a) not yours and b) insecure. In general, though, whenever you have an HTTPS page that accesses anything (scripts, frames, images) from an HTTP page, it'll throw you a warning. However, with iframes, the browser will shut you down, with most of them disabling the iframe completely unless the user confirms that they want to access the content. I'm not sure how lenient IE6 is with this, but if there's anything that's the slightest bit fishy about the way you're accessing the content, the browser is not going to like it. You shouldn't have an issue if the HTTPS page is accessing HTTPS content, but you need to scope out all of your resources (perhaps in another browser?) to make sure that you're accessing everything securely.
3) Also keep in mind that the page you're accessing (though it may be secure itself) may access insecure resources. I would recommend going to that page and checking its resources as well, because the browser will still count it accessing those resources insecurely as your page accessing them insecurely.
Related
I've read quite some post about the angularjs html5Mode including this one and I'm still puzzled:
What is it good for? I can see that I can use http://example.com/home instead of http://example.com/#/home, but the two chars saved are not worth mentioning, are they?
How is this related to HTML5?
The answers links to a page showing how to configure a server. It seems like the purpose of this rewriting to make the server return always the same page, no matter what the URL looks like. But doesn't it read to needlessly increased traffic?
Update after Peter Lyons's answer
I started to react in a comment, but it grew too long. His long and valuable answer raises some more questions of mine.
option of rendering the actual "/home"
Yes, but that means a lot of work.
crazy escaped fragment hacks
Yes, but this hack is easy to implement (I did it just a few hours ago). I actually don't know what I should do for in case of the html5mode (as I haven't finished reading this seo article yet.
Here's a demo
It works neither in my Chromium 25 nor in my Firefox 20. Sure, they're both ancient, but everything else I needed works in both of them.
Nope, it's the opposite. The server ONLY gets a full page request when the user first clicks
But the same holds for the hashbang, too. Moreover, a user following an external link to http://example.com/#!/home and then another link to http://example.com/#!/foreign will be always served the same page via the same URL, while in the html5mode they'll be served the same page (unless the burdensome optimization you mentioned gets done) via a different URL (which means it has to be loaded again).
but the two chars saved are not worth mentioning, are they?
Many people consider the URL without the hash considerably more "pretty" or "user friendly". Also, a very big difference is when you browse to a URL with a hash (a "fragment"), the browser does NOT include the fragment in it's request to the server, which means the server has a lot less information available to deliver the right content immediately. As compared to a regular URL without any fragment, where the full path "/home" IS including in the HTTP GET request to the server, thus the server has the option of rendering the actual "/home" content directly instead of sending the generic "index.html" content and waiting for javascript on the browser to update it once it loads and sees the fragment is "#home".
HTML5 mode is also better suited for search engine optimization without any crazy escaped fragment hacks. My guess is this is probably the largest contributing factor to the push for HTML5 mode.
How is this related to HTML5?
HTML5 introduced the necessary javascript APIs to change the browser's location bar URL without reloading the page and without just using the fragment portion of the URL. Here's a demo
It seems like the purpose of this rewriting to make the server return always the same page, no matter what the URL looks like. But doesn't it read to needlessly increased traffic?
Nope, it's the opposite. The server ONLY gets a full page request when the user first clicks a link onto the site OR does a manual browser reload. Otherwise, the user can navigate around the app clicking like mad and in some cases the server will see ZERO traffic from that. More commonly, each click will make at least one AJAX request to an API to get JSON data, but overall the approach serves to reduce browser<->server traffic. If you see an app responding instantly to clicks and the URL is changing, you have HTML5 to thank for that, as compared to a traditional app, where every click includes a certain minimum latency, a flicker as the full page reloads, input forms losing focus, etc.
It works neither in my Chromium 25 nor in my Firefox 20. Sure, they're both ancient, but everything else I needed works in both of them.
A good implementation will use HTML5 when available and fall back to fragments otherwise, but work fine in any browser. But in any case, the web is a moving target. At one point, everything was full page loads. Then there was AJAX and single page apps with fragments. Now HTML5 can do single page apps with fragmentless URLs. These are not overwhelmingly different approaches.
My feeling from this back and forth is like you want someone to declare for you one of these is canonically more appropriate than the other, and it's just not like that. It depends on the app, the users, their devices, etc. Twitter was all about fragments for a good long while and then they realized their mobile users were seeing too much latency and "time to first tweet" was too long, so they went back to server-side rendering of HTML with real data in it.
To your other point about rendering on the server being "a lot of work", it's true but some consider it the "holy grail" of web app development. Look at what airbnb has done with their
rendr framework. See also Derby JS. My point being, if you decide you want rendering in both the browser and the server, you pick a framework that offers that. Not that you have a lot of options to choose from at the moment, granted, but I wouldn't advise hacking together your own.
If you follow a link out of my webpage, how can I ensure the webpage reloads when the user returns?
Especially: if the link loads in a separate window, how can I reload my webpage then?
I am wondering about the approaches, especially any that avoid javascript, and what their pros and cons are.
The best way to go about this kind of problem is to request the browser doesn't cache the page - so that it simply has to reload each time.
The accepted way to do this is with the Cache-Control HTTP header, specifically setting it to no-cache, however there are a couple of possibilities depending on exactly the behaviour you want.
I need to detect when an URL redirects the browser to another location, including javascript redirects. I thought of using an actual web browser engine with javascript support to achieve this, by loading and interpreting the html from the url and setting some sort of "hook" to be notified whenever the browser changes the address.
Can anyone tell me if that's possible and with what browser engine? Or if there's a better method doing this task?
You can't. There will always be a way around your code. Frames, framebusting, 202 status codes, iframes, ajax content loading, and more.
You can write code that covers most cases, but it won't be 100% effective. What's the reason you're trying to do this? Maybe there's a better solution.
If I display abc.jpg 20 times on a web page, does loading of the web page cause 20 http requests to the abc.jpg? Or it depends if I am using relative or absolute paths?
Thanks
It's down to the browser. A poorly written browser may request the same file multiple times, but any of the widely-used browsers will get this right. It shouldn't matter whether they are using relative or absolute paths (though mixing between relative and absolute paths on the same page might trip up some browsers, so you should probably avoid it).
It depends on the web browser, but any modern browser should only request it once.
It is up to the browser. A modern browser will try hard to cache the image. Use consistent URL format in your requests when possible - consistent capitalization, don't use "www." one time and no "www." another time, etc.
Download Firebug and use the 'Net' tab to inspect all requests.
For this case, I agree with the other answers, any modern browser with proper settings should cache it.
It does depend on the browser settings but it also depends on what the web server tells the client to do with the image.
See this, it's quite complicated
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
While I agree with the above statements, I suggest looking at your web server access log for the target image and comparing the referring page and browser fingerprint.
You will possibly see lots of hits to HEAD rather than GET in order to make sure the file cache is up to date.
I am trying to get an iframe B communicate with site A.
I've searched and searched and every thing I read says it's impossible if they are of different domain (the iframe src is coming from a sub domain).
I want to communicate because my company has ads on its page and it needs to refresh them every X minutes. This is ok if it's a normal add, but some adds extend. Like I have adds that start with 300x250 and then get to 800x300.
I wanted to communicate to the iframe to know when the add was going to expand but it just doesn't seem to be a way. Is there any way to let the add go beyond the initial size of the iframe?
If the add is 300x250 the iframe will also have 300x250, but when the add expands it get's cut off, so I really need to either get the iframe to expand also or have the add go beyond the size of the iframe.
Anyone know how to do this or have some tutorial that shows how to have some basic communication to an iframe.
Note: There are some websites that also serve adds that have a totally different domain, so it would be great if someone knew how to make it go beyond the iframe.
Thanks
If you want the two iframes to communicate and you say one is on a different subdomain but the same top-level domain, you can do inter-frame scripting. See http://ajaxian.com/archives/how-to-make-xmlhttprequest-calls-to-another-server-in-your-domain.
The trick is to get page A and B to both set
document.domain = 'SameTopLevelDomain.com';
and the browser will then let the pages communicate (eg grab data from the other, call functions, etc).
However if the two pages are on different domains altogether, you'd have to take the server-side proxy approach as answered earlier.
You can't cross iframe boundaries for security reason, it would be straightforward to steal your login credentials to any site if that would be possible.
However you can make server side proxy, which would redirect every query from iframe to ads servers. That way your iframe could actually have source in the same domain (or subdomain)
There is a way to do cross-domain communication using iframes, described in an answer to Resizing an Iframe based on content.
Many ad-serving companies serve their banners on your site via iframes, and use the technique outlined in the answer above to ensure that the iframe can expand to the full required size of the creative.
Maybe my answer Cross-site AJAX requests will help you.