Моя идеальная установка заключалась бы в том, чтобы взять текущий сайт клиентов, загрузить .htaccess с регулярным выражением внутри, которое будет соответствовать URI, и если он найдет определенное расширение файла, он будет использовать тот же путь, но с измененным доменом.
т.е.
Нормальный путь:
http://www.domain.com/something/images/someimage.jpeg
http://www.domain.com/assets/js/jquery.js
.htaccess с переводом превратит приведенное выше в:
http://mycdn.other.com/something/images/someimage.jpeg
http://mycdn.other.com/assets/js/jquery.js
Я гуглил это часами подряд, безуспешно. Опять же, это для фактического использования Amazon CloudFront. S3 уже подключен к веб-сайту для резервного копирования и хранения файлов с помощью s3fs, но это не решает проблему, поскольку он использует S3 напрямую, а не через CloudFront.
Протестировано и работает на httpd-2.2.3-31.el5.centos
Метод перенаправления:
RewriteEngine On
RewriteCond %{REQUEST_URI} .*jpg$|.*gif$|.*png$ [NC]
RewriteRule (.*) http://www.google.com/$1 [R]
R приведет к фактическому перенаправлению страницы на новый домен, что может быть, а может и не быть именно тем, что вы ищете.
Прокси-метод:
RewriteEngine On
RewriteCond %{REQUEST_URI} .*jpg$|.*gif$|.*png$ [NC]
RewriteRule (.*) http://www.google.com/$1 [P]
P вызовет прокси (при условии, что у вас установлен mod_proxy), который будет сохранять контент, поступающий с вашего сервера, вместо перенаправления. Это заставит ваш сервер выполнять больше работы и будет генерировать значительно большую пропускную способность ввода-вывода, чем перенаправление. Прокси-серверы дороги, но они гарантируют, что все отображается в одном домене вместо доступа к удаленному серверу или CDN для контента.
Изменить: я обновил его, чтобы использовать request_URI вместо request_filename, таким образом файлы внутри субдиректорий, которые не существуют, по-прежнему будут прокси / перенаправить.