А я бы бил за использование htaccess, как ни крути это оверхед и костыль, причем костыль привязаный к 1 веб-серверу — апачу. В современном мире нельзя привязывать продукт к 1 серверу

Roosso 14 окт 2012 в 01:07

Костыль если у тебя хотя бы VPS и уж тем более VDS
Но на виртуальном хостинге, к сожалению без данного костыля жить в разы труднее.

4umak 16 окт 2012 в 07:16

>> Костыль если у тебя хотя бы VPS и уж тем более VDS

А расскажите, пожалуйста, в чём разница между VPS и VDS?:)

Roosso 16 окт 2012 в 13:09

Вопрос с подвохом?

4umak 16 окт 2012 в 13:20

Вопрос как вопрос — в чём разница между VPS и VDS?

Roosso 16 окт 2012 в 16:20

Я спросил, потому что мне показалось, что вы пытаетесь подначить меня своим вопросом.
Если вам и правда интересно, по большому счету почти никакой. В первом случае железо виртуальное, во втором реальное. (хотя я не уверен, что это стандартное разделение… но хостеры у нас обычно разделяют такие вещи)

4umak 16 окт 2012 в 16:28

На самом деле, технической разницы под этими двумя терминами нет никакой. Просто так сложилось, что «у нас» (СНГ и пр) принято виртуальный сервер называть VDS, а «у них» — VPS.

Всё остальное — лишь домыслы и попытки неумелого маркетинга некоторых «хостеров» :)

Roosso 16 окт 2012 в 16:34

Ну собственно пост для РФ.
А неумелый маркетинг у нас по всюду.

Насколько я знаю, принципе везде таков: VPS дают минимальные конфига, а под VDS конфиги помощнее.
Наверное все из-за волшебного слова Dedicated во второй аббревиатуре.

Хотя некий процент VDS называет выделенные серверка (непонятно тогда причем тут Virtual… Но я уже давно смирился с Рашей) а под VPS виртуальные.

4umak 16 окт 2012 в 16:37

> Хотя некий процент VDS называет выделенные серверка (непонятно тогда причем тут Virtual…

[sarcasm]VERY Dedicated же....:) [/sarcasm]

НЛО прилетело и опубликовало эту надпись здесь

Roosso 17 окт 2012 в 09:33

Ох уж эти маркетологи и сисадмины ;)

НЛО прилетело и опубликовало эту надпись здесь

porcelanosa 14 окт 2012 в 01:31

а что не так с ним? Это просто файл настройки — не более того. Или я что то не понимаю? И это не привязка продукта — это настройка окружения

Roosso 14 окт 2012 в 01:46

Может у человека свой сервак под столом.
Хотя как по мне, если мне нужны разные настройки под разные сайты, я точно не полезу в httpd.conf их переписывать, даже если у меня будет к нему доступ. Или в php.ini

Bal 14 окт 2012 в 17:50

Включение htaccess заставляет сервер при каждом запросе обшаривать каталоги от запрошенного вверх до корня сайта. Что отрицательно сказывается на производительности. Поэтому на нагруженных серверах его поддержку выключают. А сервера, изначально заточенные на производительность вообще не имеют аналогичного механизма.

Roosso 14 окт 2012 в 18:34

А если htaccess положить в каждый каталог!?
А можете какие нибудь результаты тестов производительности привести что бы было ясно о каком проценте производительности идет речь.

Bal 15 окт 2012 в 01:29

В каждый каталог или не в каждый, а пройти придётся до корня, потому что .htaccess в нижележащих каталогах переопределяют, действия .htaccess из более высоколежащих, но не отменяют их совсем.

Наконец, добрался до тестов. Нулевой файл в каталоге с вложенностью пять от корня. ab -n10000 -c100. Q6600, 4Гб. Apache не оптимизированный, так как на домашней машине только для тестов. Gentoo, 64bit. По 4-5 тестов.

При AllowOverride All выдаёт 8,1..8,8 тыс. запросов в секунду. С AllowOverride None — 10,8-12,3 тыс.

Это на простаивающей машине, где кроме Apache ничего в это время не грузило. Если дисковая система будет чем-то занята, то разница может стать ещё больше.

Roosso 15 окт 2012 в 01:49

Сильно…
Стоит подумать над оптимизацией этого процесса…

Кстати, не знаете, а если не будет htaccess Апач, будет пытаться его искать!?

Bal 15 окт 2012 в 02:20

Вот у меня в примере, как раз, .htaccess и отсутствовали. Естественно, apache должен убедиться, что этих файлов нет и просмотреть все каталоги от запрашиваемого до корня сайта.

С работающим .htaccess должно быть ещё немного медленнее — прочитать, распарсить…

Mendel 14 окт 2012 в 19:21

Ну если уж совсем-совсем строго, то апач не очень совсемстим с хайлоадом. А если мы его за легким кэширующим фронтом прячем, то такие мелочи как хтаксесс погоду не сделают.

С другой стороны дефакто хтаксесс работает на подавляющем большинстве виртуальных хостингов и по умолчанию на всех вдс.

Bal 15 окт 2012 в 01:32

В общем, да. Apache считается достаточно тяжеловесным сервером. И хотя я его под высокой нагрузкой не практикую, люди с прямыми руками умудряются его разгонять до вполне конкурентоспособной производительности. И отключение .htaccess — это обычно первая операция в разгоне :)

Ну а что на виртхостах включён — так это там единственный способ конфигурить свою систему простому юзеру :) Я ради этого его тоже держу, пускать в песочницу знакомых и т.п. Там не только .htaccess работает, там mpm_itk задействован, который вообще почти в 10 раз снижает скорость :)

rodweb 14 окт 2012 в 01:04

Создатели HTML5 Boilerplate предлагают свой вариант идеального .htaccess, рекомендую ознакомиться.

Roosso 14 окт 2012 в 01:09

Не было ещё времени капнуть этот продукт.
Уже в закладках на ближайшие исследования, но руки ещё не дошли.

А прямую ссыль на рекомендации по htaccess не подскажите?

pornstar 14 окт 2012 в 01:19

github.com/h5bp/html5-boilerplate/blob/master/.htaccess

Roosso 14 окт 2012 в 01:24

Спасибо.
Очень интересно.
Вы только что потратили пару моих часов отведенных на сон.

Замечу, что для новичков сложноваты некоторые из приемов.

tarya 14 окт 2012 в 01:46

Это все очень хорошо и я всегда внимательно читаю такие заметки в вношу изменения в свои файлы конфигурации но есть одно НО. Заметил что размещая сайты на зарубежных хостингах (у нас такого не замечал) например на хостере 1&1 или veeble все эти настройки не работают! Сайт вечно выпадает в 500. Благо у меня уже опыт появился и 4 проекта успешно работают. Но приходится чуть не все отрубать. Прописывать специальные опции чтоб работал PHP как не странно и все такое. Никакие php_value не работают и так далее. И главное вот буквально месяца два назад сдал проект, клиент доволен, временно его домен крутится на моем домашнем сервере — начинаю переносить не работает ничего. Я клиенту обьяснил что ограничения безопастности мол пол инета жалуется на ограничения хостера — он говорит давайте я на другом куплю. Купили на veeble -ну тлже самое, просто страх.

Roosso 14 окт 2012 в 01:50

Честно говоря с зарубежными хостерами мало сталкивался…
А чем их саппорт объясняет такие действия?

А VPS у них брать не пробовали? Все таки возможностей натыкать модулей больше становится.

И насчет заметок и внесения изменений в файлы. Я такой… Там выше ссылоку даже на один очень интересный .htaccess почитайте. Мне очень понравилось. Куча полезностей разных.

tarya 14 окт 2012 в 11:36

## this line is specific for 1and1 hosting
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Вот такое нужно прописать на 1&1, нашел в их саппорте, иначе не работает PHP, пятая версия или нет, но все просто колом встает и все.

Сейчас сравнил разные .htaccess с разных тех сайтов, так на вскидку не скажу, но есть свои особенности что работает а что нет.

Options -MultiViews

Вот так на Veeble нужно дописать вместе к Options +FollowSymLinks иначе не работает mod_rewrite.

НЛО прилетело и опубликовало эту надпись здесь

Roosso 14 окт 2012 в 03:10

Если я правильно понял, то речь не только о php_value… А вообще о большинстве директив и опций htaccess

НЛО прилетело и опубликовало эту надпись здесь

Roosso 14 окт 2012 в 03:45

Это да. Вообще конечно надо подправить пост и указать там условие <ifModule mod_php.c> чем сейчас и займусь.

НЛО прилетело и опубликовало эту надпись здесь

Andrey_Zentavr 14 окт 2012 в 05:02

… Для тех у кого всё получилось, идём на webpagetest.org мерять красоту до и после.
Кстате, не мешало бы сказать копи-пастерам что

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteBase /
    RewriteCond %{HTTP_HOST} ^black-web
    RewriteRule (.*) http://www.black-web.ru/$1 [R=301,L]
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
    RewriteRule ^index\.php$ http://www.black-web.ru/ [R=301,L]
</IfModule>

… может не работать не так как ожидаеться во всяких самописных штуках ( я не про тех, у кого Joomla/Wordpress/Drupal/etc)

Roosso 14 окт 2012 в 06:05

За ссыль, спасибо.

А насчет самописных штук. Тут все от рук зависит. Но трудно представить, что бы человек навернул код так, что бы данные условия не работали. Этож как надо извернуться в коде, что бы это вызвало ошибки в перенаправлениях.

dobriykot 14 окт 2012 в 12:18

Что-то у вас по адресу www.black-web.ru/alex.roosso выдается текст скрипта, а не сама страничка.

Mendel 14 окт 2012 в 13:04

Читал когда-то, что под большой нагрузкой у апача (к сожалению не помню версию и актуальность темы) бывает такая фича, что он перестает считывать хтаксесс и выполняет все по умолчанию, а иногда и вообще без того же пхп к примеру.
Я не думаю что это именно тот случай, но я параноик и не то что расширения вот так вот не меняю, но даже у стандартных пхп делаю по старинке:

<?php
// Проверим что нас вызвали откуда надо, а не напрямую...
if (!defined('dummyCONSTANT')) die('I love U baby.....');

Хоть у меня и идет:

RewriteCond %{REQUEST_FILENAME} !index\.php$
RewriteRule ^.*\.php$ /index.php [L,QSA]

ПЫСЫ: когда почините Вашу настройку по расширению подмигните плиз… Хочу еще один момент проверить…

radist2s 14 окт 2012 в 16:48

Вот это:
if (!defined('dummyCONSTANT')) die('I love U baby.....');
никак не спасает от того, если апач решит отдать страницу как текст.
Кстати, что-то подобное кажется случалось на фриланс.ру.
Ну и если хочется спец-расширений для скриптов, то лучше уж тогда из прописать в конфиге апача для определенного виртуального хотса, если конечно есть доступ.

Mendel 14 окт 2012 в 19:26

Не спасает, но хоть что-то… Есть решение лучше?
В принципе есть — держать конфиг ниже корня, но это не работает для типовых решений — не каждый пользователь поймет куда это его просят залить конфиг :)

radist2s 14 окт 2012 в 19:34

Почему нет, например сам конфиг можно прикрыть вот так:

<files config.php>
order allow,deny
deny from all
</files>

Примерно также можно прикрыть доступ к остальным скриптам, кроме index.php и подобного, но оно не так нужно. Главное конфиг прикрыть.

Mendel 14 окт 2012 в 20:05

Хорошая шутка, поржал, спасибо.
Держать конфиг выше корня это хотя-бы ДОСТУПНО на любом хостинге (ну почти).
Не понятно, но доступно. А это… в общем кроме как «поржал» других слов нет.

radist2s 14 окт 2012 в 20:07

А в чем собственно заключалась моя шутка?

Roosso 14 окт 2012 в 18:38

Починил…

Кстати тоже по старинке проверяю место запуска скрипта.

Roosso 14 окт 2012 в 18:37

О да… Щерт…
Снова обновил htaccess и забыл просто строчку с указанием addhandler
Спасибо.

roman01la 14 окт 2012 в 13:50

Литература от гуру .htaccess made easy

vadimus 14 окт 2012 в 18:10

Спасибо! Наконец-то статья написанная легко и ясно.

RouR 15 окт 2012 в 07:47

Вы молодец, что в примерах прописали ifModule. Новички часто ищут статьи про .htaccess, но редко кто из их (да и авторы статей не всегда) задумываются про обработку ошибок конфигурации.

Roosso 15 окт 2012 в 09:25

Я даже отдельно указал об этом ниже под примером.
Но кстати тоже заметил, что при постинге люди забывают упоминать о данном факте. (Хотя большая половина идет перепостом, поэтому кто где в самом начале накосячил не установить)

Renius 15 окт 2012 в 12:57

#кэшировать флэш и изображения на месяц

Header set Cache-Control «max-age=2592000»

А я вот тут картинки обновил на сервере. У пользователя они будут через месяц?
Js на неделю? у меня 3-4 выкатки на staging в день, большая часть касается js css
Html на день?
Да что такое, почему? Почему вы предлагаете ограничить возможность изменения данных на уровне веб сервера?

Mendel 15 окт 2012 в 13:22

Вообще было и не раз, что крупные сервисы отражают в именах статики версию файла. По крайней мере пару лет назад так работали все CDN которые не для публики а для себя… вполне себе логика, если уж так невтерпеж менять дизайн и прочее динамически.

Что касается html, то автор разделяет php и html. По логике у него html это статика…
Хотя согласен, об этом нюансе стоит рассказать, ибо если не анализировать то можно не заметить (я анализировал ибо ищу хорошие решения для своего фреймворка и автоматом уже вижу у кого что и как сделано даже по косвенным признакам :)

Renius 15 окт 2012 в 13:51

Кешированием должен заниматься сервер приложений. max-age — жестокий брутфорс, в моих приложениях он всегда 0.
Я с трудом могу представить себе систему в которой контент не меняется динамически. Homepage?
Я не считаю себя крупным серdиcом, у меня всего 10 картинок на амазоне лежит, однако пути к ним все s3-eu-west-1.amazonaws.com/foo-bar/magnify.jpg?1350015777. А браузер пусть сам запоминает видел ли он эту картинку или нет.
Весь html динамический, кэш отдает сервер приложений, потому, как веб-сервер не может знать, изменились ли данные объекта и, соотвественно, изменилось ли содержимое представления.

Веб серверу нельзя управлять кешированием! Однако, веб сервер должен уметь читать заголовки в которых ему четко и ясно скажут, что свежак, а что 304.

Mendel 15 окт 2012 в 14:19

Сильно зависит от задачи.
Я статику тупо отдаю по умолчанию ибо если она критична, то уж надо оптимизировать по взрослому, если не критична, то и дефолты справятся…
Но на моей практике полно задач в которых контент относительно статичен, и необходимая динамика терпит тот же час к примеру для динамики аж бегом.
А согласитесь динамический кэш в базе довольно мутная тема, которая требует лишний раз напрягаться — начинающий разраб этого делать не будет. Так что в простых задачах лучше ну его нафиг, и если есть возможность то отдать это на откуп вебсерверу.

Если же мы говорим о реально серьезном проекте, то модулей может быть не много, а очень много… прописывать логику кэширования в каждом конкретном случае бывает лень, тем более что уровень разрабов на прикладных участках не всегда высок. И тут довольно неплохо показывает себя многоуровневая схема — в некритичных участках ставим кеширование по времени + 304 по ётагу… а уже перед этим механизмом кэширования стоит динамический кэш приложения, который может отдать значение задержки в ноль (я обычно все развно 1-5 сек даю), и вручную уже через свой кэш выбирать когда обновлять а когда нет…

Итого если совсем упрощенно, то я бы сказал, что в простых задачах кеширование вебсервером полезно, и в больших тоже полезно… а в середине оно действительно неуместно :)

Renius 15 окт 2012 в 15:20

Интересно.
В общем ваши тезисы мне понятны. Я, для себя, не принимаю следствие, т.к. повсеместно использую кеширование, везде предусматривая callbacks, когда кеш теряет актуальность, но это, как мне кажется — предмет диалога, нежели спора.
Однако начинающие разрабы поставят max-age и будут утверждать, что google chrome кэширует method DELETE. Отсутствие лишнего напряжения может привести к многочасовому дебагу в виду того, что разработчик «скопипастил серебряную пулю и растолкал по папкам».
Вы, возможно, возразите, что «хождение по мукам» неизбежно для разработчика, но я возражу, что, например, неделя для js — вызывает butthurt в 146% случаев, и подводить к такому спорному решению — зло.

Mendel 15 окт 2012 в 17:49

Ну на счет динамического контента согласен. У меня на него по умолчанию 1сек стоит во вьюве, если не указать другое число. Что касается статики, тот тут сильно-сильно от проекта зависит. Если сделал и забыл, то почему бы и не держать неделю статику? Если же постоянно идут изменения и релиз на продакшен уходит чаще чем раз в месяц, то у заказчика явно хватит денег чтобы покрыть расходы на ресурсы для значительно более короткого периода кэширования…
Вообще с общей тезой о том, что над временем кэша нужно думать индивидуально а не засовывать это в типовое решение я согласен… По здравому размышлению даже и не пойму никак чего я спорю то? :)

Renius 16 окт 2012 в 05:17

А не спорили мы. Я наблюдаю две адекватные точки зрения на проблему. Приятно провел время, спасибо. :)

Roosso 15 окт 2012 в 18:45

Настраивайте как удобней.
Я вам панацею предложил?
И как написали ниже неужели трудно вставлять js таким образом:

<link rel="stylesheet" type="text/css" href="style.css?v=1" media="screen" />

или

<link rel="stylesheet" type="text/css" href="style.css?sid=5sdf4fs...." media="screen" />

Roosso 15 окт 2012 в 18:48

И в догонку…

Скажем у вас баннеры jpg которые не надо кешеровать. Сложите их в отдельную папку и в неё положите .htaccess у которого кеш изображений будет минуту или 2 секунды.

Renius 16 окт 2012 в 05:37

Скажем jpg банеры нужно кешировать, поэтому fingerprint + max-age=0

Renius 16 окт 2012 в 05:23

Зачем тогда max-age?

Roosso 16 окт 2012 в 13:10

Не понял вопрос. Уточните, если не трудно.

Renius 16 окт 2012 в 15:54

Если вы контролируете версию style.css, значит вы контролируете версию style.css. Т.о. max-age для style.css == 0. Потому как не веб сервер контролирует версию файла, а вы. Отсюда вытекает вопрос: зачем max-age отличный от 0.

Roosso 16 окт 2012 в 16:22

Срок жизни указываем для загруженной пользователем версии.
Обновили свой стиль. Появилась новая версия. И грузится пользователю, как новая версия, а не как старая. Но при это кешируется, до появления следующей версии или истечения срока жизни.

Mendel 16 окт 2012 в 21:11

Вопрос был в том, почему не бесконечный срок жизни, если при смене все равно другой адрес будет.
Тут такое дело… С одной стороны с нулем мы замусореваем кэш клиента, с другой стороны вечным он все равно не будет, и по какому-то принципу и так чистится, так что можно и вечным сделать если такой статики не очень-очень много, и она не меняется очень-очень часто…

Roosso 16 окт 2012 в 21:16

В принципе то верно.
Но зачем дожидаться, когда у человека иссякнет место под кеш или наступит время удаления по настройкам браузера.
У хрома вообще по-умолчанию мало места под кеш, а у Осла так почти немерено по сравнению с другими браузерами. И у осла кстати постоянно глючит автоматическая чистка кеша.

Я все таки наверное склонюсь к тому, что под данным углом зрения на эту проблему — это больше вопрос вежливости.

Mendel 16 окт 2012 в 23:21

Ниадназначна… Ему мои полтора файла погоду не сделают. А вот мне стопитсот лишних запросов погоду сделать могут. Тут оно конечно 304, но вообще по разному бывает.
Хотя согласен, что в 99% случаев неделя или месяц будет вполне нормально

Renius 17 окт 2012 в 07:46

Годный вышел холивар. Я так и не могу однозначно сказать чья точка зрения в итоге верна.
Но в попытке номер два, по созданию идеального .htaccess, я бы уделил этим тонкостям больше внимания :)

Roosso 16 окт 2012 в 21:15

оффтопик

~~тут был пост не к месту...~~
А как удалить пост?

Mendel 16 окт 2012 в 23:20

Никак. Я вообще уверен, что тема с бесконтрольным редактированием сообщений не вечна, и что скоро сделают у отредактированных постов возможность видеть старую версию. Это больше соответствует духу Хабра :)

Roosso 17 окт 2012 в 01:53

Было бы классно.
Сразу было бы понятно, что человек имел ввиду и что написал… =) Правда все быстро привыкнуть и снова станут за собой следить.

Tomasina 18 окт 2012 в 20:14

как перенаправить всех, кроме посетителей из известной сети (по IP)?

Roosso 19 окт 2012 в 02:01

Примерно так:

<IfModule mod_setenvif.c>
	SetEnvIf REMOTE_ADDR 192.168.1.1 REDIR="redir"
</IfModule>
<IfModule mod_rewrite.c>
	RewriteEngine on
	RewriteBase /
	RewriteCond %{REDIR} redir
	RewriteRule ^/$ /target.php
</IfModule>

SCT 8 ноя 2013 в 22:57

У меня после

<IfModule mod_setenvif.c>
    SetEnv TZ Europe/Moscow
</IfModule>

сайт упал на 500 ошибку. По этому я юзаю такой вариант

php_value date.timezone Europe/Moscow

А кэшик настроил так:

# Разрешение кеширования в этой папке
# Необходимо включение модулей
# mod_headers.c и mod_expires.c
#
<IfModule mod_expires.c>
	ExpiresActive on
	#ExpiresDefault "access plus 1 hours"
	#ExpiresDefault "access plus 10 years"
	ExpiresDefault                          "access plus 1 month"
	ExpiresByType text/cache-manifest       "access plus 59 seconds"
	ExpiresByType text/html                 "access plus 59 seconds"
	ExpiresByType text/xml                  "access plus 59 seconds"
	ExpiresByType application/xml           "access plus 0 seconds"
	ExpiresByType application/json          "access plus 0 seconds"
	ExpiresByType application/rss+xml       "access plus 1 hours"
	ExpiresByType image/x-icon              "access plus 1 week"
	ExpiresByType image/gif                 "access plus 1 year"
	ExpiresByType image/png                 "access plus 1 year"
	ExpiresByType image/jpg                 "access plus 1 year"
	ExpiresByType image/jpeg                "access plus 1 year"
	ExpiresByType video/ogg                 "access plus 1 year"
	ExpiresByType audio/ogg                 "access plus 1 year"
	ExpiresByType audio/mp3                 "access plus 1 year"
	ExpiresByType video/mp4                 "access plus 1 year"
	ExpiresByType video/webm                "access plus 1 year"
	ExpiresByType text/x-component          "access plus 1 month"
	ExpiresByType font/truetype             "access plus 1 year"
	ExpiresByType font/opentype             "access plus 1 year"
	ExpiresByType application/x-font-woff   "access plus 1 year"
	ExpiresByType image/svg+xml             "access plus 1 month"
	ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
	ExpiresByType text/css                  "access plus 1 hours"
	ExpiresByType application/javascript    "access plus 2 months"
	ExpiresByType text/javascript           "access plus 2 months"
<IfModule mod_headers.c>
	Header append Cache-Control "public"
</IfModule>
</IfModule>

Roosso 11 ноя 2013 в 11:39

сайт упал на 500 ошибку. По этому я юзаю такой вариант

Странно…

А кэшик настроил так:

Сугубо личное дело ;)

shkomg 17 окт 2014 в 18:02

А что про это скажете — тут попытки продолжаются: github.com/h5bp/server-configs-apache

(сюда ведет ссылка с developers.google.com)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий