Too Many Redirects - CDN Rewrite Rule

[Kiril Kalchev]

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-forum at 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 at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130322/92747bfb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3565 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130322/92747bfb/attachment-0001.bin>