$GLOBALS[‘config’][‘resource_versions’] = array(
‘foo.gif’ => ‘2.1’,
‘/css/main.css’ => ‘1.27’,
‘/javascript/md5.js’ => ‘6.1.4’,
Затем мы меняем нашу функцию в шаблоне, чтобы она могла использовать эти номера версий при реальной работе.
function smarty_version($args){
if ($GLOBALS[‘config’][‘is_dev_site’]){
$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);
$version = $stat[‘mtime’];
$version = $GLOBALS[‘config’][‘resource_versions’][$args[‘src’]];
echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);
Таким образом, нам не нужно переименовывать файлы или даже запоминать, когда мы изменяли их содержимое, — URL автоматически будут изменяться каждый раз, когда мы перерабатываем сайт. В общем, почти приехали.
В разговоре об отправке заголовков, обеспечивающих долговременное хранение статических ресурсов в кэше, мы отметили, что если отдача контента реализована не на PHP, то простого способа добавления таких заголовков не существует. Чтобы справиться с этой проблемой, мы можем либо все же использовать PHP, либо переложить задачу модификации заголовков на Apache.
Использовать для нашей цели PHP нетрудно. Мы просто должны изменить правила rewrite для статических файлов, чтобы они проходили через PHP-скрипт, и написать сам скрипт, который будет выдавать нужные заголовки, перед тем как передать эти файлы по запросу.
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /redir.php?path=$1$2 [L]
header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()+315360000).“ GMT»);
header(«Cache-Controclass="underline" max-age=315360000»);
# ignore paths with a ‘..’
if (preg_match(‘!..!’, $_GET[path])){ go_404(); }
# make sure our path starts with a known directory
if (!preg_match(‘!^(javascript|css|images)!’, $_GET[path])){ go_404(); }
# does the file exist?
if (!file_exists($_GET[path])){ go_404(); }
# output a mediatype header
$ext = array_pop(explode(‘.’, $_GET[path]));
switch ($ext){
case ‘css’:
header(«Content-type: text/css»);
case ‘js’ :
header(«Content-type: text/javascript»);
case ‘gif’:
header(«Content-type: image/gif»);
case ‘jpg’:
header(«Content-type: image/jpeg»);
case ‘png’:
header(«Content-type: image/png»);
header(«Content-type: text/plain»);
# echo the file’s contents
echo implode(‘’, file($_GET[path]));
function go_404(){
header(«HTTP/1.0 404 File not found»);
Несмотря на то что такой подход работает, это не лучшее решение. PHP в сравнении с Apache требует больше памяти и времени на исполнение. Кроме того, нам необходимо соблюдать осторожность из-за возможных эксплойтов. Дабы избежать всей этой головной боли, мы можем попытаться использовать Apache напрямую. Директива RewriteRule позволяет нам устанавливать значения переменных окружения при срабатывании директивы, тогда как директива Header добавляет заголовки лишь в том случае, когда присвоенно значение заданной переменной. Комбинируя две эти директивы, мы легко можем составить нужную цепочку инструкций:
RewriteEngine on
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]
Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» env=VERSIONED_FILE
Header add «Cache-Control» «max-age=315360000» env=VERSIONED_FILE
Из-за порядка исполнения Apache, мы должны добавить строчку Re-writeRule в главный конфигурационный файл (httpd.conf), а не в .htaccess, иначе строчки Header будут исполнены первыми, перед установкой переменной окружения. Сами строчки Header могут быть размещены и в главном конфигурационном файле, и в .htaccess — их местоположение ни на что не влияет.
Сокращенный перевод.
© 2006 Carson Systems, Vitamin
Оригинал: www.thinkvitamin.com/features/webapps/serving-javascript-fast
РЫНКИ: Ну и как тебя называть?
Автор: Виктор Шепелев
Unix отсутствует. Просто не существует в природе. То есть нет такой конкретной вещи, в которую можно ткнуть пальцем и сказать: «Вот это — Unix». А все остальное тогда будет никакой не Unix. Собственно говоря, удивительный термин *nix (и даже — *n?x, как дань Linux) — результат вот этого несуществования единственно правильного Unix’а.
Причиной такого положения дел стал антимонопольный комитет США. Не стоит сразу представлять себе судебный процесс «Консервативная монополия Unix мешает развитию новой перспективной ОС Windows». Антимонопольный процесс против American Telephone and Telegraph (AT&T) в 1949 году помешал распространению влияния телекоммуникационного гиганта на новорожденные отрасли: AT&T было запрещено заниматься продажей каких бы то ни было компьютерных решений, и рекомендовалось ограничиться телефоном и телеграфом.
Именно поэтому исследовательское подразделение AT&T, Bell Labs, с тех пор прибыли само по себе не приносило: все создаваемые компьютерные технологии свободно лицензировались всем желающим. Если бы не это, еще неизвестно, как сложилась бы судьба созданной в Bell Labs операционной системы Unix. Многие из лицензиатов (в основном, конечно же, университеты) создавали слегка или сильно модифицированные версии для собственных нужд. Одной из этих версий, созданной в университете Беркли, Калифорния ничем не примечательным аспирантом Биллом Джоем, была уготована долгая и извилистая судьба.
В начале 1980-х годов в результате очередного антимонопольного судебного процесса AT&T была разделена на несколько подразделений, в результате чего у корпорации оказались развязаны руки (в смысле получения прибыли от торговли компьютерами). И вновь — тяжело предположить, как бы сложилась судьба Unix без этого события: с одной стороны, агрессивный маркетинг AT&T способствовал быстрому и эффективному распространению ОС; с другой — новая стратегия лицензирования (без исходного кода) положила начало разделению разработки Unix на несколько разных независимых веток и многолетнему противостоянию этих веток (так называемые unix wars).
Одной из «веток» стал разработанный в Беркли «берклиевский набор софта» (Berkeley Software Distribution, BSD), по прежнему распространявшийся свободно и с исходниками. Возможно, именно этот факт повлиял на DARPA[На всякий случай: DARPA — Defense Advanced Research Projects Agency (Агентство перспективных исследований при Министерстве обороны США) — так или иначе поддерживало огромную часть исследований, которые сформировали образ современных IT] при выборе — кому бы дать денег для разработки протокола TCP/IP. Дали. Разработали (4.2BSD, август 1983 года). Этот фактор (совместно со многими другими) повлиял на огромную популярность и быстрое распространение BSD. Ну а Билл Джой, с которого начиналась эта версия Unix, тем временем создал собственную фирму под названием «Солнышко».
Оригинальная Unix System V от AT&T, созданная в Беркли BSD, Sun OS от Sun Microsystem и еще несколько дистрибутивов, основанных на System V и BSD, вступили в сложное взаимодействие, включавшее и конкуренцию, и заимствование полезных фич, и юридические споры — в общем, было весело. Однако все это привело к размытию образа Unix и потере ориентиров в стиле «лебедь, рак и щука». Попытки исправить ситуацию привели к очередному пату: AT&T и Sun скоординировались и создали System V version 4, а многие независимые производители, которым не понравился этот альянс гигантов, объединились в Open Software Foundation[Не путать с Free Software Foundation — ничего общего!] и попытались создать «свой» Unix по имени OSF/1 (в общем, это была неудачная попытка)[Вообще говоря, у них там все еще сложнее получилось: сначала группа независимых поставщиков Unix создала группу по его стандартизации X/Open, в ответ на это объединились AT&T и Sun; а уже это привело к появлению Open Software Foundation].
Этот жизнерадостный период (конец 80-х — начало 90-х), называемый Unix wars, имел много интересных последствий: считается, что пока юниксопроизводители воевали друг с другом, Windows захватил десктопы, а внезапно появившийся Linux — сердца простых юниксоидов, которым скандалы производителей были до фени. Впрочем, в данном контексте нам будут намного интереснее другие последствия противостояния.
А последствия были такие: программистам стало очень печально жить. Как водится, в результате маркетинговых войн (когда каждый стремится сотворить систему круче чем у прочих) совместимость различных клонов Unix пошла на убыль. То есть программа, написанная под какую-нибудь Sun OS, совершенно не обязательно станет работать под какой-нибудь другой BSDI (хотя, по идее, и то и другое — Unix). Менеджерам-маркетологам этот вопрос был, в общем, без разницы («а так даже лучше — чего это наши программы будут работать под ОС конкурента?»), но, к счастью, культура Unix всегда определялась скорее программистами и продвинутыми пользователями, нежели менеджерами.