My server deliver page via HTTPS (as well as any resource on the page). The page by itself comes from main domain: domain.com, while other resources such as images or css comes from the following subdomains:
img.domain.com and css.domain.com respectively. Images and css resources have Cache-Control in response headers, i.e. they should be cached.
The question is why the browser requests images and css resources each time I open the page?
On other hand, if all resources comes from the same domain - everything is taken from the cache? Why it is so? And it looks like this behavior is not the same in different browsers: in some browsers I see conditional requests while in others - unconditional. Is there any standard for such case?
Is Cache-Control set to public for the resources from the alternative domains?
This is a bit of an ancient (2009) article that might help - http://blog.httpwatch.com/2009/01/15/https-performance-tuning/
I'd also consider whether you want to serve the CSS from a separate host...
the browsers going to have to do a DNS lookup, and open up a new TCP connection
if you used the same host DNS lookup goes away, connection overhead may go away (IE9, Chrome speculatively open a second connection), but you get the overhead of the HTTPS negotiation back.
I don't know the right answer without measuring but it's worth thinking about.
Related
Sometimes, if I go to a website, such as this one through an HTTP link, it looks fine and works as apparently intended:
However, if you change the address to be HTTPS, the page loads without any browser warnings but looks really weird and seems broken—spacing is messed up, the colors are wrong, fonts don't load, etc.:
All of this same stuff happens in both Firefox and Chrome on my computer.
What causes this to happen? How can I avoid this if I make an HTTPS-secured website?
For me the browser tells you what is wrong in a warning message. Parts of the page are not secure (such as images).
What does this mean? The developer of the site has linked some content such as CSS, JS, or images using HTTPS links and some using HTTP links.
Why is this a problem? Since some content is being retrieved over an insecure connection (http), it would be possible for malicious content to be injected into your browser which could then grab information which was transmitted over https. Browsers have had this warning for a very long time, but in the interest of security they have hedged their behavior on the more secure side of things now.
What will fix this? There is nothing we can do as consumers of the website. The owner of the site should fix the problem. If you are really interested in viewing the site and not concerned about security, you can temporarily disable this protection from the URL bar warning message in Firefox.
As #micker explained, the page looks weird because not all of the sources are loading since their connections could not be made securely and the website's ability to load those sources are being denied by the browser for not being referenced using a secure connection.
To elaborate further. in case it's still not quite clear, a more accurate and technical explanation would be that, for styling a webpage, the Cascading Style Sheets, or CSS, is the language used to describe the presentation of a document or webpage in this case, and tells the browser how elements should be rendered on the screen. If you consider these stylesheets as sort of building blocks, where you can combine them together to define different areas on a webpage to build one masterpiece, then you would see why having multiple building blocks for a site would sound pretty normal.
To save even more time, rather than try to figure out the code for each and every stylesheet or "building block" that I want to include, I can burrow someone else's style sheet that has the properties I want and link to it as a resource instead of making or hosting the resource myself. Now if we pretend that there's a stylesheet for every font size change, font color variance, or font placement, then that means we're going to need a building block to define each of those
Now, If I am on a secure connection, then the browser ensures that connection stays secure by only connecting to other sites, or resources, which are also secure. If any of the sites containing the building blocks of CSS that I want to use but are not secure, AKA not using SSL (indicated by a lack of "s" in "http://" in their address), then the browser will prevent those connections from happening and thus prevents the resources from loading, because the browser considers it a risk to your current secure connection.
In your example's particular case, things looked fine when you entered only http:// without the https:// because the site you were visiting doesn't automatically force visitors to use SSL and lets you connect to it using the less secure, http protocol, which means your browser is not connecting securely to it, and therefore won't take extra steps to protect you by blocking anything outside of that since you're already on an insecure connection anyway. In which case, the browser doesn't need to prevent sources that are coming from an insecure connection or sites because in a way, your connection is already exposed so it can freely connect where it needs to and load any resources regardless if they can be transferred securely or not.
So then, when you go to the "https://" version of the site, there are no browser warnings because you're connecting to that site with a secure connection and unfortunately that also means that if the designer of the page had linked resources from somewhere that just didn't have an SSL connection available or didn't update the link to go to the new https:// standard, then it's going to be considered insecure and since you're on a secure connection, the browser will block those connections which means blocks those resources from being able to load, making the page load incomplete with not all of its building blocks. Build blocks that tells your screen to move all the text on the right into a panel and to have a blue font color while changing to a different font face. Those definitions defining the look and appearance didn't make it through and so those sections adopted whatever existing stylesheet is present which normally don't match with what was intended to be there.
I have a https site and need to show content from other sites that may or may not be themselves https. Predictably enough, I'm getting warning messages like this in the console...
"Mixed Content: The page at 'https://www.example.com/' (my server) was loaded over HTTPS, but requested an insecure image 'http://www.aninsecuredomain.com/image.jpg'. (not my server) This content should also be served over HTTPS."
(not to the mention the fact that I no longer see the little padlock displayed properly in most browsers who now consider my site's network insecure).
I've read through a bunch of posts on SO on this topic, but I can't seem to find a definitive answer on whether there's anything I can do when I don't own the external servers (so can't guarantee they'll have a https version). Appreciate any thoughts on whether this is possible, and if so how I could go about achieving it!
When you need to include content from another domain in an https webpages you can:
Make the owner of the other domain commit to https by explaining him the security reason behind that
Proxy the content through your website or host it yourself (if you have right to do it)
(If you don't see the padlock anymore it's because your page is no longer secure because it include insecure elements that could have been tempered: it's not they "consider my site's network insecure", it is indeed insecure!)
You should use the // prefix. (instead of http[s]://)
On an https page, the secure version wil be loaded.
On on a plain http page, the plain http version will be loaded.
Edit your theme replacing every occurence of http://fonts.googleapis.com/... with //fonts.googleapis.com/...
I have a site with HTTPS configured.
My client wants me to embed a youku video. At first the browser blocked the iframe since it had HTTP protocol on it.
I changed it to HTTPS and now youku does not work. It seems youku does not support HTTPS.
is there any way around this?
Perhaps there is a service other than youku that does support HTTPS and is still suitable for that region?
hi，we had supported（sorry for later）
for example:
1
<iframe height=498 width=510 src='https://player.youku.com/embed/XMTg3Nzg4MzY4NA==' frameborder=0 'allowfullscreen'></iframe>
2
https://player.youku.com/player.php/sid/XMTg3Nzg4MzY4NA==/v.swf
3:
<embed src='https://player.youku.com/player.php/sid/XMTg3Nzg4MzY4NA==/v.swf allowFullScreen='true' quality='high' width='480' height='400' align='middle' allowScriptAccess='always' type='application/x-shockwave-flash'></embed>
Youku player serves some resources (like preview images or alternative sources for video) under http, not https - and this might be the main culprit of "partially insecure content" issue in browsers. This problem is caused by Youku player itself, it's quite possible to change the code loaded from their servers.
However, the problem can be solved in most simple and convenient way by rewriting insecure http requests on given page with secure https requests - it possible to achieve this by including CSP meta tag in page header:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
The "Content-Security-Policy" response header allows to control resources the user agent is allowed to load on given page (more information here).
What "upgrade-insecure-requests" directive does: "Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten."
The original solution was found in this post.
We have an existing web product that uses a lot of static images, css files, js libs and other static content. Whenever a page is loaded, browser usually has to make dozens of additional HTTP requests to retrieve all that content which almost doubles load time. We wanted to put the content to Amazon's CloudFront to improve the load times and I am trying to choose between the two possible ways of implementing this.
1). Going through every single reference to such content and replacing it with a request to CloudFront. E.g. images/image.jpg would become qwerty.cloudfront.net/images/image.jpg. This will result in a "true" integration but it would be practically impossible for me to implement this. Especially for different JS libs which come with their own images that they choose dynamically.
2). Leave images/image.jpg as it is and tell server to do 301 to CloudFront for such requests. The problem with this implementation is that the requests will actually have to be routed all the way to the server before server can redirect them to CloudFront.
So basically I am not sure if 301 is a good idea. This will work only if the time to route request to our server is negligible compared to the time it takes server to send this image back to the client. Additionally I don't know how easily server will handle load spikes - will it survive if a traffic spike happens and it will have to serve a lot of 301 redirects (although I assume it will, since doing this should be much easier than retrieving the files from file system and outputting them). Please let me know if you have any experience with this or thoughts on the matter (including other potential ways of implementing this integration).
I haven't had a huge opportunity to research the subject but I figure I'll just ask the question and see if we can create a knowledge base on the subject here.
1) Using subdomains will force a client side cache, is this by default or is there an easy way for a client to disable it? More curious about what kind of a percentage of users I should be expecting to affect.
2) What all will be cached? Images? Stylesheets? Flash SWFs? Javascripts? Everything?
3) I remember reading that you must use a subdomain or www in your URL for this to work, is this correct? (and does this mean SO won't allow it?)
I plan on integrating this onto all of my websites eventually but first I am going to try to do it for a network of flash game websites so I am thinking www.example.com for the website will remain the same but instead of using www.example.com/images, www.example.com/stylesheets, www.example.com/javascript, & www.example.com/swfs I will just create subdomains that point to them (img.example.com, css.example.com, js.example.com & swf.example.com respectively) -- is this the best course of action?
Using subdomains for content elements isn't so much to force caching, but to trick a browser into opening more connections than it might otherwise do. This can speed up page load time.
Caching of those elements is entirely down the HTTP headers delivered with that content.
For static files like CSS, JS etc, a server will typically tell the client when the file was modified, which allows a browser to ask for the file "If-Modified-Since" that timestamp. Specifics of how to improve on this by adding some extra caching headers would depend on which webserver you use. For example, with Apache you can use the mod_expires module to set the Expires header, or the Header directive to output other types of cache control headers.
As an example, if you had a subdirectory with your css files in, and wanted to ensure they were cached for at least an hour, you could place a .htaccess in that directory with these contents
ExpiresActive On
ExpiresDefault "access plus 1 hours"
Check out YSlow's documentation. YSlow is a plugin for Firebug, the amazing Firefox web development plugin. There is lots of good info on a number of ways to speed up your page loads, one of which is using one or more subdomains to encourage the browser to do more parallel object loads.
One thing I've done on two Django sites is to use a custom template tag to create pseudo-paths to images, css, etc. The path contains the time-last-modified as a pseudo directory. This path component is stripped out by an Apache .htaccess mod_rewrite rule. The object is then given a 10 year time-to-live (ExpiresDefault "now plus 10 years") so the browser will only load it once. If the object changes, the pseudo path changes and the browser will fetch the updated object.