The 2nd option defeats most of the purpose of a CDN.

Nicholas

*Nicholas Tang**:*
VP, Dev Ops

nicholas.tang@livestream.com
|
t: +1 (646) 495 9707
|
m: +1 (347) 410 6066
|
111 8th Avenue, Floor 15, New York, NY 10011
[image: www.livestream.com] http://www.livestream.com/



On Fri, Jan 7, 2011 at 8:36 PM, Ilan Berkner <iberkner@gmail.com> wrote:

> At this time we're delivering static content, in particular, audio files
> ~5K in size directly through our server, for a number of reasons, we're
> looking at moving delivery of these files to a remote storage / CDN
> facility.
>
> Question re. URL requests for these files. Currently, these file are
> served through a request like this:
> http://www.ourdomain.com/sounds/a/alpha.mp3. If we switched to a remote
> storage / CDN solution, the URL of course would change to something else.
> There are 2 options ( I think ):
>
> 1. Modify the application code to make the the call directly to the new
> URL.
>
> 2. Instruct Nginx through a location clause to redirect such traffic to
> another URL, for example:
>
> location /sounds/*.mp3 {
> rewrite http://www.cdn.com/$1 ...
> }
>
> Is there a preferred way or does it matter? I guess the first option would
> probably be preferred as it further reduces the work load done by the
> server, even as simple as parsing the URL... Any thoughts / suggestions
> would be appreciated.
>
> Also, does anyone have a recommendation / experience with any particular
> remote storage / CDN such as Rackspace CloudFile, Amazon S3, Limelight,
> CacheFly, etc?
>
> Thanks
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx
>
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx