How to become an author
Search
Write a publication
Pull to refresh

Comments 43

etag — это, емнип, нововведение http1.1
а last-modified — соответственно http1.0, оставленное для обратной совместимости
Total votes 1: ↑1 and ↓0+1
Ну у меня бы первый вопрос напросился: а зачем, если уже есть один механизм? Собстенно он и возникал.
Total votes 4: ↑3 and ↓1+2
затем, что он более продвинутый
Total votes 1: ↑1 and ↓0+1
Перенесите, пожалуйста, в блог «Клиентская оптимизация»
This comment wasn’t rated yet0
а вообще информация о языке должна быть частью url
Total votes 19: ↑16 and ↓3+13
Ну это тема для отдельного холивара. Я, например, не вижу в этом никакого смысла. Язык берется из сессии/куков, а если там ничего об этом не сказано, то тот, который просит клиент в заголовках запроса.
Total votes 6: ↑4 and ↓2+2
поисковики так хуже индексят — они же cookie не поддерживают
Total votes 5: ↑5 and ↓0+5
Есть подозрение, что они поддерживают http заголовки.
Total votes 5: ↑2 and ↓3-1
ну, значит, не все заголовки :)
Total votes 2: ↑2 and ↓0+2
А мне кажется, что это даже противоречит лицензии поисковиков.
Total votes 3: ↑0 and ↓3-3
основной принцип хттп, между прочим, это то, что ресурс однозначно определяется урлом. но можно ему не следовать, конечно же, и етаги руками мастерить.
Total votes 12: ↑12 and ↓0+12
UFO just landed and posted this here
Ага, а как тогда ссылку дать на страницу на конкретном языке?
Total votes 13: ↑13 and ↓0+13
Для чего вам давать ссылку на конкретном языке? Зачем за получателя решать на каком языке ему хотелось бы прочитать контент.

В любом случае, мне кажется это не самое подходящее место для обсуждения этого вопроса.
Total votes 18: ↑2 and ↓16-14
Уникальной единице информации должен соответствовать уникальный URL. Конкретному URL — строго конкретная единица информации на конкретном языке. Разные языки (разные документы с физически разным содержимым) — разные URL. И дело не в поисковиках, а в простом здравом смысле.
Total votes 20: ↑19 and ↓1+18
Это все замечательно, пока речь идет об информации а не о формах, инструментах и т д.
К примеру, если в gmail будет отдельная ссылка на каждый язык интерфейса-- это уже выглядит победой теории над здравым смыслом.

Это не ради холивара; это просто к тому что не надо так категорично высказываться. У каждого правила есть своя область применимости
Total votes 4: ↑4 and ↓0+4
У каждого правила есть своя область применимости
Несомненно, веб-интерфейсы — тема особая. Тем не менее, нет ничего страшного в раздельных URL-адресах для каждого языка в том числе и применительно к сервисам типа Gmail. Главное — не забыть дать пользователю наглядную возможность вручную выбрать нужный язык при необходимости.

Следует также учитывать, что, как и с обычными веб-страницами, совпадение перечней веб-страниц у разных языковых версий веб-интерфейса не является гарантированным. С раздельными URL’ами никогда (даже теоретически) не возникнет проблемы, когда англоговорящий человек даёт ссылку русскоговорящему, и тот попадает на страницу 404.
Total votes 3: ↑1 and ↓2-1
Как варианты: www.example.com/doc.html возвращает док на языке пользователя (из сессии), www.example.com/doc.html?ln=en возвращает английский док вне зависимости от сессии. И либо редиректы, если ты зашел без языка, либо на самой странице ссылки для языковых версий документа.
This comment wasn’t rated yet0
Дописываешь hl=ru в GET-параметрах :)
Total votes 2: ↑1 and ↓10
Представьте себе, ну, например, международный форум. У каждого пользователя в настройках указано, на каком языке будут надписи на кнопочках и т.п. (в то время как к непосредственному контенту это не имеет отношения). Какого, простите, черта, в ссылке должен содержаться язык?!
Total votes 3: ↑3 and ↓0+3
Если контент (не логотип и не кнопки, а контент) вне зависимости от выбранного языка один и тот же, то и URL имеет смысл использовать один и тот же.
Total votes 1: ↑1 and ↓0+1
зависимость от языка реализуется с помощью Vary, нет?

С ETag'ами, кстати, проблемы разные есть еще. Например, с ними gzip не работает иногда. YSlow за ETag'и даже баллы снимает.
Total votes 1: ↑1 and ↓0+1
нет, проблем нет, YSlow в данном месте глючит (хотя в правилах там как раз двусмысленно написано)
This comment wasn’t rated yet0
это как вы ETag захотите выставлять. Его и ведь динамически (через тот же PHP) можно определять, а Last-Modified вообще не предполагает какой-то gzip-зависимой метки.
nginx последних версий, кстати, лишен этого бага
This comment wasn’t rated yet0
Про Last-Modified речи и не шло. Ну и как-бы это не вариант всю статику через php прогонять. Да, и довольно логично, что ngnix последних версий лишен бага из багтрекера апача :)
This comment wasn’t rated yet0
:) я к тому, что сейчас, в принципе, нет никаких предпосылок НЕ использовать ETag, а на кластерах он чуточку лучше (ведь Google, например, в SVN его и использует)
This comment wasn’t rated yet0
я прекрасно понял, что Вы предлагаете статику отдавать ngnix'ом, а E-tag'и определять динамически в скриптах, но это ведь не отменяет того факта, что YSlow может вполне правильно указывать на наиболее распространенную нерабочую комбинацию ETag+Apache+mod_deflate.
This comment wasn’t rated yet0
Все было бы хорошо, если бы Вы упоминали, в каких случаях эта комбинация не работает: когда мы запросили одним и тем же клиентом (например, прокси-сервером) сначала несжатую версию контента, затем сжатую — получили бы 304-ответ (при использовании If-None-Match) и отдали бы сжатую вместо несжатой. Только для статики существует Vary: User-Agent, Content-Encoding, которые данную проблему позволяют решить (в случае нормальных прокси-серверов, конечно :)

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

Поэтому многие рекомендуют отключать ETag на крупных проектах.
Total votes 1: ↑1 and ↓0+1
да, но Google именно ETag использует. На больших проектах, где много статики, обычно не Apache используют. А ETag более конфигурируемый в этом плане, чем Last-Modified
Total votes 1: ↑1 and ↓0+1
зачем же его выключать? Достаточно задать:

FileETag -INode
This comment wasn’t rated yet0
Я просто видел несколько докладов/презентаций, где чуваки говорили «да, ETag это хорошо, но вот у нас из-за него дофига запросов мимо кэша, поэтому вырубили».

Да и суть тэгов не в том, чтобы их просто посылать, а посылать правильные значения :)
This comment wasn’t rated yet0
Дык, конечно :) Смысл ETag в том, чтобы он менялся, если меняется контент.
Total votes 1: ↑1 and ↓0+1
cache-control: private поможет
Total votes 1: ↑0 and ↓1-1
Поправьте пожалуйста концовочку 4го абзаца ;)
This comment wasn’t rated yet0
«URL для разных языков один и тот же,»

последний абзац вы именно на этот случай написали?:-)
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr