[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: mod_rewrite и череда преобразований
Гость_Алексей
Здравствуйте!

Столкнулся с проблемой..

В mod_rewrite использую вот такую конструкцию:
  RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)\.(\d+)\.(js|css|png|jpe?g|gif)$ $1.$3

для версионности подключаемых файлов (подробнее здесь) и сброса кэша браузера. Т.е. в html-коде можно писать filename.346467345.ext, которого не существует, а это правило перенаправит на существующий filename.ext. Очень удобно.

Но вот теперь встала необходимость после этого преобразования перенаправлять изображения через свой обработчик:
  RewriteRule \.(jpe?g|gif|png)$ images-handler.php

Код images-handler.php (выводит путь к обрабатываемому изображению):
$document_root  = $_SERVER['DOCUMENT_ROOT'];
$requested_uri = parse_url(urldecode($_SERVER['REQUEST_URI']), PHP_URL_PATH);

$requested_file = basename($requested_uri);
$source_file = $document_root.$requested_uri;
die($source_file);

Но вот беда - как заставить эти 2 правила работать вместе?

В php-обработчик попадает не обработанный, исходный путь, будь-то с цифрами или без них. А надо, чтобы после преобразования из filename.346467345.ext в filename.ext в php-handler попадало преобразованное имя файла, т.е. без цифр. Но что-то у меня не выходит :-( Я уж и так его, и сяк, а всё бестолку..

Помогите, пожалуйста!

https://github.com/h5bp/html5-boilerplate/b...d#cache-busting
killer8080
Цитата (Гость_Алексей @ 21.01.2013 - 21:26)
для версионности подключаемых файлов (подробнее здесь) и сброса кэша браузера. Т.е. в html-коде можно писать filename.346467345.ext, которого не существует, а это правило перенаправит на существующий filename.ext. Очень удобно.

чего удобного то? Чем традиционный query string не угодил?

Цитата (Гость_Алексей @ 21.01.2013 - 21:26)
Но вот теперь встала необходимость после этого преобразования перенаправлять изображения через свой обработчик: 

RewriteRule \.(jpe?g|gif|png)$ images-handler.php

а сервак положить не боишься?
Игорь_Vasinsky
killer8080
а

<img src="handler.php?pathtofile.ext&param=..."/>


тоже тяжело будет?

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
АльОшка
Цитата (killer8080 @ 21.01.2013 - 21:26)
чего удобного то? Чем традиционный query string не угодил?

Вот документация h5b к этому моменту: https://github.com/h5bp/html5-boilerplate/b...d#cache-busting
А вот здесь рассказывается, что при использовании строки запроса сквид не сбрасывает свой кэш: http://www.stevesouders.com/blog/2008/08/2...se-querystring/

Цитата (killer8080 @ 21.01.2013 - 21:26)
а сервак положить не боишься?

Чем? Тем, что через доп.обработчик все изображения проходят? Так нагрузка не сильно увеличивается - там суть такая - взять изображение, произвести манипуляции и сохранить новый файл в фс.
При следующем обращении к этому изображению происходит проверка - файл обработан? отдаём его. нет? обрабатываем и снова отдаём его. Разница не существенна, в принципе. Нагрузка только при первом обращении.
И заголовки правильные отдаются, чтобы браузер нормально закэшировал.
Или есть другие подводные камни?

Цитата (Игорь_Vasinsky @ 21.01.2013 - 21:59)
<img src="handler.php?pathtofile.ext&param=..."/>
тоже тяжело будет?

не то, чтобы тяжело, но:
1. плохо для поисковиков.
2. подмена не прозрачна (надо именно прозрачно подменять, от лишних глаз)
killer8080
Цитата (АльОшка @ 22.01.2013 - 01:45)
А вот здесь рассказывается, что при использовании строки запроса сквид не сбрасывает свой кэш: http://www.stevesouders.com/blog/2008/08/2...se-querystring/

и где там об этом написано? Всё с точностью до наоборот
Цитата
I wasn’t aware of any performance difference, but in a meeting this week a co-worker, Jacob Hoffman-Andrews, mentioned that Squid, a popular proxy, doesn’t cache resources with a querystring.

...

Proxy administrators can change the configuration to support caching resources with a querystring, when the caching headers indicate that is appropriate. But the default configuration is what web developers should expect to encounter most frequently.
Там сказано что при настройках по умолчанию сквид не кеширует запросы с query string. И что? Оно вам надо? Достаточно того что браузер кеширует файлы. К тому же реальное количество юзеров ходящих через прокси настолько мизерно, что этим вообще можно пренебречь, в плане нагрузки на сервер. К тому же тут возникает закономерный вопрос, в какой конфигурации работает сервер? На хостингах традиционно используют связку nginx+apache или lighttpd+apache. Сам по себе апач слишком тяжел, поэтому для отдачи статики целесообразней использовать легкий фронтэнд, а апач стоит бэкэндом только для обработки скриптов. При такой настройке, статику будет всегда отдавать апач, тут нужно десять раз подумать, имеет ли смысл, лишаться такого преимущества, и создавать дополнительную нагрузку серверу и тормоза, ради того чтоб мифические пользователи сквида имели возможность пользоваться благами его кеша.

Цитата (АльОшка @ 22.01.2013 - 01:45)
Чем? Тем, что через доп.обработчик все изображения проходят? Так нагрузка не сильно увеличивается - там суть такая - взять изображение, произвести манипуляции и сохранить новый файл в фс.

и как это вяжется с этим правилом?
Цитата (Гость_Алексей @ 21.01.2013 - 21:26)
RewriteRule \.(jpe?g|gif|png)$ images-handler.php

Я тут не вижу генерации картинок on demand, по этому правилу абсолютно все картинки сервер будет отдавать скрипту. Или у вас расчет на то, что статику перехватит nginx?
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.