views:

570

answers:

5

We have several images and PDF documents that are available via our website. These images and documents are stored in source control and are copied content on deployment. We are considering creating a separate image server to put our stock images and PDF docs on - thus significantly decreasing the bulk of our deployment package.

Does anyone have experience with this approach?

I am wondering about any "gotchas" - like XSS issues and/or browser issues delivering content from the alternate sub-domain?

+1  A: 

Pros:

-load balancing

-isolating a different functionality

Cons:

-more work (when you create a page on the main site you would have to maintain the resources on the separate server)

Things like XSS is a problem of code not sanitizing input (or output for that matter). The only issue that could arise is if you have sub-domain specific cookies that are used for authentication.. but that's really a trivial fix.

Patrick Gryciuk
A: 

If you're serving HTTPS and you serve an image from an HTTP domain then you'll get browser security alert warnings pop up when you use it.

So if you do HTTPS, you'll need to buy HTTPS for your image domain awell if you don't want to annoy the hell out of your users :)

There are other ways around this, but it's not particularly in the scope of this answer - it was just a warning!

joshcomley
If James is saying what I think he is, which is that the image is actually delivered by script that outputs the content (i.e., content-type: image/jpeg); then as long as the script is on the secure server (https://secure.domain.com/somescript.php?i=4567aldh), this should not be a problem. Then again, I might be the one misunderstanding the setup....
Fran Corpier
(oops, forgot to escape the https part. It turned it into a link. Sorry. :/)
Fran Corpier
The "There are other ways around this" was referring to exactly that - a script on the HTTPS that fetches the images from the other server. So you're absolutely right, it's not a real problem!
joshcomley
+5  A: 

Pro:

Many browsers will only allocate two sockets to downloading assets from a single host. So if index.html is downloaded from www.domain.com and it references 6 image files, 3 javascript files, and 3 CSS files (all on www.domain.com), the browser will download them 2 at a time, with the other blocking until a socket is free.

If you pull the 6 image files off onto a separate host, say images.domain.com, you get an extra two sockets dedicated to download your images. This parallelizes the asset download process so, in theory, your page could render twice as fast.

Con:

If you're using SSL, you would need to either get an additional single-host SSL certificate for images.domain.com or a wildcard SSL certificate for *.domain.com (matches any subdomain). Failure to do so will generate a warning in the browser saying the page contains mixed secure and insecure content.

Chris Sears
If you were really concerned with performance, and had large resources downloading, you could put them on a domain with an * in the dns, and then randomize the subdomain in the resource call, like http(s)://<randomstring>.imagesomain.com/image.gif, etc. This could give you as many sockets as there are resources and speed your load quite a bit.
Eli
You actually don't want to take this too far or you may see a net loss in performance. I wouldn't use more than 4 static asset hosts (ie "images1.domain.com", "images2.domain.com", "images3.domain.com", "images4.domain.com") for most sites. The main issues will degrade performance as you increase the number of asset hosts are caching and HTTP keep-alives. The same file downloaded from one asset host will not be considered cashed on another asset host. And HTTP keep-alives allow the same TCP connection to be reused for multiple requests. 1 to 4 hosts gives you a good balance.
Chris Sears
+2  A: 

You will also, with a different domain, not send the cookies data with every request. This can increase performance.

alex
+1  A: 

Another thing not yet mentioned is that you can use different web servers to serve different sorts of content. For example, your static content could be served via lighttpd or nginx while still serving your dynamic content off Apache.

ceejayoz