pashka_r Dec 2 2009 at 10:53

ETag спешит на помощь

2 min

42K

Client optimization*

+32

Comments 43

tenshi Dec 2 2009 at 11:58

etag — это, емнип, нововведение http1.1
а last-modified — соответственно http1.0, оставленное для обратной совместимости

pashka_r Dec 2 2009 at 12:15

Ну у меня бы первый вопрос напросился: а зачем, если уже есть один механизм? Собстенно он и возникал.

tenshi Dec 3 2009 at 02:09

затем, что он более продвинутый

sunnybear Dec 2 2009 at 12:04

Перенесите, пожалуйста, в блог «Клиентская оптимизация»

pashka_r Dec 2 2009 at 12:17

так и сделал

evilbloodydemon Dec 2 2009 at 12:51

а вообще информация о языке должна быть частью url

pashka_r Dec 2 2009 at 12:59

Ну это тема для отдельного холивара. Я, например, не вижу в этом никакого смысла. Язык берется из сессии/куков, а если там ничего об этом не сказано, то тот, который просит клиент в заголовках запроса.

sunnybear Dec 2 2009 at 13:00

поисковики так хуже индексят — они же cookie не поддерживают

pashka_r Dec 2 2009 at 13:05

Есть подозрение, что они поддерживают http заголовки.

sunnybear Dec 2 2009 at 13:29

ну, значит, не все заголовки :)

MaksimMukharev Dec 2 2009 at 23:45

А мне кажется, что это даже противоречит лицензии поисковиков.

evilbloodydemon Dec 2 2009 at 13:20

основной принцип хттп, между прочим, это то, что ресурс однозначно определяется урлом. но можно ему не следовать, конечно же, и етаги руками мастерить.

UFO just landed and posted this here

tenshi Dec 3 2009 at 02:14

http header vary

Bonch Dec 2 2009 at 13:23

Ага, а как тогда ссылку дать на страницу на конкретном языке?

pashka_r Dec 2 2009 at 13:27

Для чего вам давать ссылку на конкретном языке? Зачем за получателя решать на каком языке ему хотелось бы прочитать контент.

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

MTonly Dec 2 2009 at 13:52

Уникальной единице информации должен соответствовать уникальный URL. Конкретному URL — строго конкретная единица информации на конкретном языке. Разные языки (разные документы с физически разным содержимым) — разные URL. И дело не в поисковиках, а в простом здравом смысле.

mjr27 Dec 2 2009 at 18:00

Это все замечательно, пока речь идет об информации а не о формах, инструментах и т д.
К примеру, если в gmail будет отдельная ссылка на каждый язык интерфейса-- это уже выглядит победой теории над здравым смыслом.

Это не ради холивара; это просто к тому что не надо так категорично высказываться. У каждого правила есть своя область применимости

MTonly Dec 2 2009 at 18:49

У каждого правила есть своя область применимости

Несомненно, веб-интерфейсы — тема особая. Тем не менее, нет ничего страшного в раздельных URL-адресах для каждого языка в том числе и применительно к сервисам типа Gmail. Главное — не забыть дать пользователю наглядную возможность вручную выбрать нужный язык при необходимости.

Следует также учитывать, что, как и с обычными веб-страницами, совпадение перечней веб-страниц у разных языковых версий веб-интерфейса не является гарантированным. С раздельными URL’ами никогда (даже теоретически) не возникнет проблемы, когда англоговорящий человек даёт ссылку русскоговорящему, и тот попадает на страницу 404.

Fduch Dec 5 2009 at 22:00

Как хорошо, что люди всё-таки оставляют возможность переключить язык руками.
www.mydigitallife.info/2009/01/11/free-unlimited-activation-product-key-to-activate-windows-7-beta/ru/

Sane Dec 2 2009 at 20:57

Как варианты: www.example.com/doc.html возвращает док на языке пользователя (из сессии), www.example.com/doc.html?ln=en возвращает английский док вне зависимости от сессии. И либо редиректы, если ты зашел без языка, либо на самой странице ссылки для языковых версий документа.

Goodkat Dec 2 2009 at 17:19

Дописываешь hl=ru в GET-параметрах :)

Dragonizer Dec 2 2009 at 22:27

Представьте себе, ну, например, международный форум. У каждого пользователя в настройках указано, на каком языке будут надписи на кнопочках и т.п. (в то время как к непосредственному контенту это не имеет отношения). Какого, простите, черта, в ссылке должен содержаться язык?!

MTonly Dec 3 2009 at 22:23

Если контент (не логотип и не кнопки, а контент) вне зависимости от выбранного языка один и тот же, то и URL имеет смысл использовать один и тот же.

kmike Dec 2 2009 at 13:29

зависимость от языка реализуется с помощью Vary, нет?

С ETag'ами, кстати, проблемы разные есть еще. Например, с ними gzip не работает иногда. YSlow за ETag'и даже баллы снимает.

sunnybear Dec 2 2009 at 13:30

нет, проблем нет, YSlow в данном месте глючит (хотя в правилах там как раз двусмысленно написано)

kmike Dec 2 2009 at 13:47

может все-таки есть?
issues.apache.org/bugzilla/show_bug.cgi?id=39727

sunnybear Dec 2 2009 at 13:53

это как вы ETag захотите выставлять. Его и ведь динамически (через тот же PHP) можно определять, а Last-Modified вообще не предполагает какой-то gzip-зависимой метки.
nginx последних версий, кстати, лишен этого бага

kmike Dec 2 2009 at 13:59

Про Last-Modified речи и не шло. Ну и как-бы это не вариант всю статику через php прогонять. Да, и довольно логично, что ngnix последних версий лишен бага из багтрекера апача :)

sunnybear Dec 2 2009 at 14:12

:) я к тому, что сейчас, в принципе, нет никаких предпосылок НЕ использовать ETag, а на кластерах он чуточку лучше (ведь Google, например, в SVN его и использует)

kmike Dec 2 2009 at 14:02

я прекрасно понял, что Вы предлагаете статику отдавать ngnix'ом, а E-tag'и определять динамически в скриптах, но это ведь не отменяет того факта, что YSlow может вполне правильно указывать на наиболее распространенную нерабочую комбинацию ETag+Apache+mod_deflate.

sunnybear Dec 2 2009 at 14:15

Все было бы хорошо, если бы Вы упоминали, в каких случаях эта комбинация не работает: когда мы запросили одним и тем же клиентом (например, прокси-сервером) сначала несжатую версию контента, затем сжатую — получили бы 304-ответ (при использовании If-None-Match) и отдали бы сжатую вместо несжатой. Только для статики существует Vary: User-Agent, Content-Encoding, которые данную проблему позволяют решить (в случае нормальных прокси-серверов, конечно :)

Т.е. проблема, конечно, есть, но при наличии прямых рук она на указанном окружении обходится (либо ее решение лежит уже за пределами данного окружения).

chikuyonok Dec 2 2009 at 17:20

Насколько я помню, есть еще очень серьезная проблема с использованием ETag на больших проектах, где статика дублируется на нескольких серверах. Из-за того, что в стандартной конфигурации апача для генерации ETag хэша используется inode файла. То есть в зависимости от того, куда направит балансировщик, получим абсолютно идентичные файлы, но разные тэги. Как результат — запрос пойдет мимо кэша.

Поэтому многие рекомендуют отключать ETag на крупных проектах.

sunnybear Dec 2 2009 at 17:39

да, но Google именно ETag использует. На больших проектах, где много статики, обычно не Apache используют. А ETag более конфигурируемый в этом плане, чем Last-Modified

bolk Dec 2 2009 at 18:17

зачем же его выключать? Достаточно задать:

FileETag -INode

chikuyonok Dec 2 2009 at 18:21

Я просто видел несколько докладов/презентаций, где чуваки говорили «да, ETag это хорошо, но вот у нас из-за него дофига запросов мимо кэша, поэтому вырубили».

Да и суть тэгов не в том, чтобы их просто посылать, а посылать правильные значения :)

bolk Dec 2 2009 at 18:22

Дык, конечно :) Смысл ETag в том, чтобы он менялся, если меняется контент.

maxcom Dec 2 2009 at 18:01

cache-control: private поможет

azeffin Dec 2 2009 at 17:46

Поправьте пожалуйста концовочку 4го абзаца ;)

pashka_r Dec 2 2009 at 18:56

Спасибо, исправил.

egorF Dec 2 2009 at 22:15

«URL для разных языков один и тот же,»

последний абзац вы именно на этот случай написали?:-)

pashka_r Dec 3 2009 at 00:34

Тонко, но нет ;)

stoune Dec 3 2009 at 18:09

Ну вобщем есть старый цыкл статтей
www.xml.com/pub/a/2006/02/01/doing-http-caching-right-introducing-httplib2.html

Ну и в Сагалаева тоже есть на русском.