0

Let me try to explain by example. Say website is hosted at example.com (NOT www.example.com). In order to serve static content cookie-free, I've chosen to use a different domain example-static.com.

Now, lets consider that my static content is currently served like this:

http://example.com/js/script.js
http://example.com/css/style.css
http://example.com/media/image.jpg

** Now I create a CNAME record aliasing example-static.com to my main domain i.e. example.com so that the static content is served as such:

http://example-static.com/js/script.js
http://example-static.com/css/style.css
http://example-static.com/media/image.jpg

** Is that all I have to do? Will all browsers execute JavaScript files and load web fonts without any security concerns? OR should I be using some .htaccess rules to modify header information and the like?

PS: It would be great if you can provide what rules should be added, if need be.

EDIT: The reason why I added a bounty to this question is that people I know have advised me against serving JS from a different domain. They aren't able to give me a clear explanation either.

its_me
  • 10,998
  • 25
  • 82
  • 130

2 Answers2

1

It will work without extra config. However: does it worth the pain? If you use some real content delivery network that's fine, but simply faking one, to be cookie-free? A much better approach would be to minimize cookie size IMHO.

Gergely Szilagyi
  • 3,813
  • 1
  • 14
  • 12
  • I need to use an extra cookie in comment form to prevent spam. So, yeah, in my case it's worth the pain. – its_me Jun 27 '12 at 03:00
  • I see. In that case the answer still holds: it'll work without any issues. (well, we can't be **really** sure about IE ever, can we? :) ) – Gergely Szilagyi Jun 27 '12 at 03:09
0

Gergely's answer answers my question. And I've also found an alternative. Since my website is served from example.com, instead of serving static content from a different domain, I am planning to serve the cookies themselves from a different sub-domain www.example.com.

Simple, and should do the job.

its_me
  • 10,998
  • 25
  • 82
  • 130
  • 1
    another option is to use cookiepath to limit the cookies to smthing like: docroot/dynamiccontent, while putting the static stuff in docroot/static or similiar – Gergely Szilagyi Jun 27 '12 at 03:22
  • 1
    on the cookie size: i had to tinker with that kinda optimization, and was shocked when i found out that the average cookie size in the client-requests were smaller than the referrer header for example. I just accepted the fact that adding 100 bytes to every HTTP request is not a big deal. (actually there's one exception: if those extra bytes will make the client request bigger than the average MTU (1500 or 1492 bytes for *DSL users) that's a big hit. It means the client has to send two packets instead of one.) – Gergely Szilagyi Jun 27 '12 at 03:32
  • @GergelySzilagyi And you've received +100 now :) – its_me Jul 06 '12 at 12:55