Hi, What Peter said is correct the best way is to prepare your application for using CDNs. But I think for a quick workaround of the problem you can try to make another server to be used only from CDN.
server {
location ~* ^.+.(jpe?g|gif|css|png|js|ico)$ {
rewrite ^
http://cdn.mydomain.com/my_sercret_cdn_location_(some_random_hash)/$request_uri?
permanent;
access_log off;
}
location ~* \.(jpg|jpeg|gif|png|flv|mp3|mpg|mpeg|js|css|ico|woff)$ {
return 301
http://cdn.mydomain.com/my_sercret_cdn_location_(some_random_hash)/$request_uri;
access_log off;
}
location /my_sercret_cdn_location_(some_random_hash) {
you can put some http_access _module rules here to allow requests only
from your CDN.
rewrite ^/my_sercret_cdn_location_(some_random_hash)(.*)$ $1 break;
pass request to your backend server;
}
}
Is there any reason of using rewrite in the first location and return in the
second. As far as I know they do the same thing in this case. You can implement
this with separate nginx server and domain instead of location. Please correct
me if I am missing something.
Regards,
Kiril
On Mar 22, 2013, at 6:31 AM, Peter Booth wrote:
> What netdna said is sensible and I imagine any cdn would say the same.
> Ultimately the ball is in your court.
>
> If you want to use a CDN (and it's not compulsory) then change your app so
> that the image links are absolute links with the cdn domain name. There's no
> good reason for nginx to have any part of this
>
> Sent from my iPhone
>
> On Mar 21, 2013, at 6:49 PM, "toddlahman" <nginx-fo...@nginx.us> wrote:
>
>> The reply I received from NetDNA after supplying the same information as I
>> did here is as follows:
>>
>> "Too many redirects" is a legit message in this scenario - example: You are
>> redirecting domain.com/file.jpg TO cdn.domain.com/file.jpg ---> request
>> comes to CDN and CDN neds to cache this file from origin so it tries to
>> fetch from origin from location "domain.com/file.jpg" ---> request comes to
>> origin and redirect rule you made redirects this request back to CDN <---
>> this is where infinite loop starts.
>>
>> This is not a proper way to implement CDN as you have to monitor who is
>> requesting your origin file so you could know whether it's a request you
>> want to redirect or not. The best way to handle this is to monitor our
>> anycast IPs and redirect everything except for those ips:
>>
>> 108.161.176.0/20
>> 70.39.132.0/24
>> 92.60.240.208/29
>> 92.60.240.217/29
>> 216.12.211.60/32
>> 216.12.211.59/32
>>
>> If you want to implement CDN this way, we can't support that implementation
>> as we don't really encourage our client to use this type of implementation.
>> The reason is quite simple: We are going to add new IP block that has to be
>> white listed and until you make update for your redirects rule you'll be
>> pushing infinite redirects to our servers causing service not to work until
>> you add new block as well.
>>
>> Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?2,237609,237661#msg-237661
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
