a mirroring CDN can't have the same hostname as you application server, because you need a way for the CDN to explicitly reference the application.
Why, in general, do sites like facebook run their CDN on a totally seperate host, not just a subdomain like cdn.facebook.com? example: http://profile.ak.fbcdn.net/hprofile-ak-snc4/173706_6103645_790537_q.jpg
Is the reason, that they can construct resource URLs with many different hostnames, to avoid the 4-connections-per-host limit on some browsers?
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies.
From: http://developer.yahoo.com/performance/rules.html#cookie_free
Because user generated content can contain nasties that may be able to access data hosted on the primary domain.
It also stops things like cookies and authentication getting sent in the request to CDN content.
Preventing users from inserting
scripts, and at the same time allowing
user submitted html is extremely
difficult to do on the server side -
ergo we must have sandboxing.
Borrowed from a fairly old whatwg post
Related
I have this one page which has an iframe inside of which a survey page is embedded, unfortunately i'm getting "Your connection is not secure" error inside the iframe. Does anyone know how to fix this issue? By the way, the website is SSL certified, not the page i'm trying include inside the iframe. Also this is a php site not wordpress.
Thanks
You are always going to have this problem when an HTTPS page references non secured content. You options are:
move the page hosting the iframe (and its associated content) outwith HTTPS. Although, in theory a HTTP page should be able to reference HTTPS hosted javascript, CSS and images without emitting warnings, this will probably vary by browser
move the survey page into HTTPS. I am guessing that you don't host this yourself - have you contacted the provider to ask if they can provide the service via HTTPS? Have you considered using a different provider?
proxy the HTTP survey page via your server - this would require some clever configuration on the webserver or terminating the SSL connection in front of a proxy operating in reverse mode for your service and rewriting/forwarding mode for the survey. Basically, if you don't control the infrastructure this is probably a non-starter.
re-implement the survey capability within your own site.
Bear in mind that as soon as your site is exposed outside of HTTPS it becomes vulnerable to more attacks.
.htaccess is not going to help - it overrides the behaviour within a vhost - the HTTP and HTTPS sites will operate in seperate vhosts.
I'm trying to optimize an html webpage, and one of the suggestions from yslow is:
Use cookie-free domains There are 11 components that are not
cookie-free
So I followed one of the standard solutions I've seen and created a subdomain static.mysite.com and put the images there.
But I'm still getting the exact same problem -- a cookie is still being delivered with each image, and same yslow message.
So how do I get this subdomain to be cookie free?
If you are using subdomain for cookie-free delivery then your main page has to use www prefix.
I had the same problem. The subdomain simply didn't work, so I used a different domain name and it solved the problem.
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.
Another benefit of hosting static components on a cookie-free domain is that some proxies might refuse to cache the components that are requested with cookies. On a related note, if you wonder if you should use example.org or www.example.org for your home page, consider the cookie impact. Omitting www leaves you no choice but to write cookies to *.example.org, so for performance reasons it's best to use the www subdomain and write the cookies to that subdomain.
Source - http://developer.yahoo.com/performance/rules.html
EDIT
If you set your cookies on a top-level domain (e.g. yourwebsite.com) all of your sub-domains (e.g. static.yourwebsite.com) will also include the cookies that are set. Therefore, in this case, it is required that you use a separate domain name to deliver your static content if you want to use cookie-free domains. However, if you set your cookies on a www subdomain such as www.yourwebsite.com, you can create another subdomain (e.g. static.yourwebsite.com) to host all of your static files which will no longer result in any cookies being sent.
For Wordpress you can use this config:
define("WP_CONTENT_URL", "http://static.yourwebsite.com");
define("COOKIE_DOMAIN", "www.yourwebsite.com");
Details - https://www.keycdn.com/support/how-to-use-cookie-free-domains/
EDIT 2
You will need to move your static content over to the wp-content folder of your newly created subdomain!
I want to implement https on only a selection of my web-pages. I have purchased my SSL certificates etc and got them working. Despite this, due to speed demands i cannot afford to place them on every single page.
Instead i want my server to serve up http or https depending on the page being viewed. An example where this has been done is ‘99designs’
The problem in slightly more detail:
When my visitors first visit my site they only have access to non-sensitive information and therefore i want them to be presented with simple http.
Then once they login they are granted access to more sensitive information, e.g. profile information for which HTTPS is used to deliver.
Despite being logged in, if the user goes back to a non-sensitive page such as the homepage then i want it delivered using HTTP.
One common solution seems to be using the .htaccess file. The problem is that my site is relatively large meaning that to use this would require me to write a rule for every page (several hundred) to determine whether it should be server up using http or https.
And then there is the problem of defining user generated content pages.
Please help,
Many thanks,
David
You've not mentioned anything about the architecture you are using. Assuming that the SSL termination is on the webserver, then you should set up separate virtual hosts with completely seperate and non-overlapping document trees, and for preference, use a path schema which does not overlap (to avoid little accidents).
A lot of big websites (facebook etc) are settings up CDN's for their content. Now I notice, that these CDN's are not always on the original domain.
Example: Facebook pictures are on "photos-a.ak.fbcdn.net"
Why is that? Is there a performance-gain in not having lots of subdomains on the "primary" domain (facebook.com)
There is quite a large performance gain for the user because with a different domain, the browser won't have to send the cookies anymore.
Read this article for more info about cookieless domains: http://code.google.com/speed/page-speed/docs/request.html#ServeFromCookielessDomain
Stackoverflow itself expains it very well on its static content site.
When the browser makes a request for a
static image and sends cookies
together with the request, the server
doesn't have any use for those
cookies. So they only create network
traffic for no good reason. You should
make sure static components are
requested with cookie-free requests.
Create a subdomain and host all your
static components there.
If your domain is www.example.org, you can host your static components on
static.example.org. However, if you've
already set cookies on the top-level
domain example.org as opposed to
www.example.org, then all the requests
to static.example.org will include
those cookies. In this case, you can
buy a whole new domain, host your
static components there, and keep this
domain cookie-free. Yahoo! uses
yimg.com, YouTube uses ytimg.com,
Amazon uses images-amazon.com and so
on.
Another benefit of hosting static components on a cookie-free domain is that some proxies might refuse to
cache the components that are
requested with cookies. On a related
note, if you wonder if you should use
example.org or www.example.org for
your home page, consider the cookie
impact. Omitting www leaves you no
choice but to write cookies to
*.example.org, so for performance reasons it's best to use the www
subdomain and write the cookies to
that subdomain.
Originally from Yahoo.
A CDN is typically spread across the world so that the user is closer to files than if all files were in the main data center.
It is difficult (impossible?) to route a single domain to different data centers.
Also, cookies no longer need to be sent. For Facebook, which has a ton of cookies due to being embedded all over the web, this can be a big saver.
I was reading in google's documentation their new pagespeed plugin, that they recommend using cookieless domains to improve performance:
Static content, such as images, JS and CSS files, don't need to be accompanied by cookies, as there is no user interaction with these resources. You can decrease request latency by serving static resources from a domain that doesn't serve cookies.
Does anybody know how to do this in IIS?
What the Google article is suggesting is that you serve all your static content from another domain where cookies are not initially set by that serving domain.
Cookies are set in two ways - by session cookies (e.g. by ASP or ASP.NET requests) or explicitly by your application.
These will be posted back TO the server on each subsequent request for the domain that set the cookie (regardless of whether the request is for static or dynamic content) thus increasing the request payload.
What you're doing by having a second domain to serve static content (HTML, CSS, Images etc) is making cookie free requests because no initial cookie would be set in the first place for that domain.
In IIS it's your application, ISAPI Filter or ISAPI extension that will add a cookie. If your IIS server is not intercepting requests for static content (because this is usually handled by the kernel mode http.sys driver) then no cookies will be added to the response. It's only further up the request pipeline that cookies come into play.
So basically there isn't a way to explicitly configure cookie-less domains in IIS.
If you simply put all your static resources into, for instance, static.mysite.com, and if you never set any cookies in that domain, then the browser will never send a cookie when retrieving a resource from your static domain.
That's all Google is saying. There's nothing to configure, just to organize.
AFAIK google analytics sets cookie for all subdomains, so it would be useless if you are using analytics?
I've experienced this also, you'd have to use a different domain altogether to avoid analytics/adsense cookies being set. Using static.yourdomain.com won't cut it.
Here's to hoping Google will change their analytics cookies so that we won't all have to buy new domains to serve cookie-less content.
AFAIK google analytics sets cookie for all subdomains, so it would be useless if you are using analytics?
Here's an example using the Google Analytics asynchronous tracking code, of how to set the domain for tracking:
_gaq.push(['_setAccount', 'UA-XXXXXXX-x'],['_setDomainName', 'www.example.com'],['_trackPageview']);
Here's an example using the previous version of tracking code:
var pageTracker = _gat._getTracker("UA-XXXXXXX-x");
pageTracker._setDomainName("www.example.com");
pageTracker._trackPageview();
and here's what Google has to say about this: Google Analytics & Cookies