Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
etag — это, емнип, нововведение http1.1
а last-modified — соответственно http1.0, оставленное для обратной совместимости
а last-modified — соответственно http1.0, оставленное для обратной совместимости
Перенесите, пожалуйста, в блог «Клиентская оптимизация»
а вообще информация о языке должна быть частью url
Ну это тема для отдельного холивара. Я, например, не вижу в этом никакого смысла. Язык берется из сессии/куков, а если там ничего об этом не сказано, то тот, который просит клиент в заголовках запроса.
поисковики так хуже индексят — они же cookie не поддерживают
основной принцип хттп, между прочим, это то, что ресурс однозначно определяется урлом. но можно ему не следовать, конечно же, и етаги руками мастерить.
Ага, а как тогда ссылку дать на страницу на конкретном языке?
Для чего вам давать ссылку на конкретном языке? Зачем за получателя решать на каком языке ему хотелось бы прочитать контент.
В любом случае, мне кажется это не самое подходящее место для обсуждения этого вопроса.
В любом случае, мне кажется это не самое подходящее место для обсуждения этого вопроса.
Уникальной единице информации должен соответствовать уникальный URL. Конкретному URL — строго конкретная единица информации на конкретном языке. Разные языки (разные документы с физически разным содержимым) — разные URL. И дело не в поисковиках, а в простом здравом смысле.
Это все замечательно, пока речь идет об информации а не о формах, инструментах и т д.
К примеру, если в gmail будет отдельная ссылка на каждый язык интерфейса-- это уже выглядит победой теории над здравым смыслом.
Это не ради холивара; это просто к тому что не надо так категорично высказываться. У каждого правила есть своя область применимости
К примеру, если в gmail будет отдельная ссылка на каждый язык интерфейса-- это уже выглядит победой теории над здравым смыслом.
Это не ради холивара; это просто к тому что не надо так категорично высказываться. У каждого правила есть своя область применимости
У каждого правила есть своя область применимостиНесомненно, веб-интерфейсы — тема особая. Тем не менее, нет ничего страшного в раздельных URL-адресах для каждого языка в том числе и применительно к сервисам типа Gmail. Главное — не забыть дать пользователю наглядную возможность вручную выбрать нужный язык при необходимости.
Следует также учитывать, что, как и с обычными веб-страницами, совпадение перечней веб-страниц у разных языковых версий веб-интерфейса не является гарантированным. С раздельными URL’ами никогда (даже теоретически) не возникнет проблемы, когда англоговорящий человек даёт ссылку русскоговорящему, и тот попадает на страницу 404.
Как хорошо, что люди всё-таки оставляют возможность переключить язык руками.
www.mydigitallife.info/2009/01/11/free-unlimited-activation-product-key-to-activate-windows-7-beta/ru/
www.mydigitallife.info/2009/01/11/free-unlimited-activation-product-key-to-activate-windows-7-beta/ru/
Как варианты: www.example.com/doc.html возвращает док на языке пользователя (из сессии), www.example.com/doc.html?ln=en возвращает английский док вне зависимости от сессии. И либо редиректы, если ты зашел без языка, либо на самой странице ссылки для языковых версий документа.
Дописываешь hl=ru в GET-параметрах :)
Представьте себе, ну, например, международный форум. У каждого пользователя в настройках указано, на каком языке будут надписи на кнопочках и т.п. (в то время как к непосредственному контенту это не имеет отношения). Какого, простите, черта, в ссылке должен содержаться язык?!
зависимость от языка реализуется с помощью Vary, нет?
С ETag'ами, кстати, проблемы разные есть еще. Например, с ними gzip не работает иногда. YSlow за ETag'и даже баллы снимает.
С ETag'ами, кстати, проблемы разные есть еще. Например, с ними gzip не работает иногда. YSlow за ETag'и даже баллы снимает.
нет, проблем нет, YSlow в данном месте глючит (хотя в правилах там как раз двусмысленно написано)
может все-таки есть?
issues.apache.org/bugzilla/show_bug.cgi?id=39727
issues.apache.org/bugzilla/show_bug.cgi?id=39727
это как вы ETag захотите выставлять. Его и ведь динамически (через тот же PHP) можно определять, а Last-Modified вообще не предполагает какой-то gzip-зависимой метки.
nginx последних версий, кстати, лишен этого бага
nginx последних версий, кстати, лишен этого бага
Про Last-Modified речи и не шло. Ну и как-бы это не вариант всю статику через php прогонять. Да, и довольно логично, что ngnix последних версий лишен бага из багтрекера апача :)
я прекрасно понял, что Вы предлагаете статику отдавать ngnix'ом, а E-tag'и определять динамически в скриптах, но это ведь не отменяет того факта, что YSlow может вполне правильно указывать на наиболее распространенную нерабочую комбинацию ETag+Apache+mod_deflate.
Все было бы хорошо, если бы Вы упоминали, в каких случаях эта комбинация не работает: когда мы запросили одним и тем же клиентом (например, прокси-сервером) сначала несжатую версию контента, затем сжатую — получили бы 304-ответ (при использовании If-None-Match) и отдали бы сжатую вместо несжатой. Только для статики существует Vary: User-Agent, Content-Encoding, которые данную проблему позволяют решить (в случае нормальных прокси-серверов, конечно :)
Т.е. проблема, конечно, есть, но при наличии прямых рук она на указанном окружении обходится (либо ее решение лежит уже за пределами данного окружения).
Т.е. проблема, конечно, есть, но при наличии прямых рук она на указанном окружении обходится (либо ее решение лежит уже за пределами данного окружения).
Насколько я помню, есть еще очень серьезная проблема с использованием ETag на больших проектах, где статика дублируется на нескольких серверах. Из-за того, что в стандартной конфигурации апача для генерации ETag хэша используется inode файла. То есть в зависимости от того, куда направит балансировщик, получим абсолютно идентичные файлы, но разные тэги. Как результат — запрос пойдет мимо кэша.
Поэтому многие рекомендуют отключать ETag на крупных проектах.
Поэтому многие рекомендуют отключать ETag на крупных проектах.
да, но Google именно ETag использует. На больших проектах, где много статики, обычно не Apache используют. А ETag более конфигурируемый в этом плане, чем Last-Modified
зачем же его выключать? Достаточно задать:
FileETag -INode
FileETag -INode
cache-control: private поможет
Поправьте пожалуйста концовочку 4го абзаца ;)
«URL для разных языков один и тот же,»
последний абзац вы именно на этот случай написали?:-)
последний абзац вы именно на этот случай написали?:-)
Ну вобщем есть старый цыкл статтей
www.xml.com/pub/a/2006/02/01/doing-http-caching-right-introducing-httplib2.html
Ну и в Сагалаева тоже есть на русском.
www.xml.com/pub/a/2006/02/01/doing-http-caching-right-introducing-httplib2.html
Ну и в Сагалаева тоже есть на русском.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ETag спешит на помощь