Hi!
> > Угу, для поддержки "тупых" серверов, которые не умеют выдавать
> > нормальные заголовки http.
> А при чем тут META?
META сама по себе совершенно не причем.
> Заголовки заголовками, но эту информацию (метаданные) где-то нужно
> задавать.
Я _второй_ раз прошу тебя не тормози, с сконцентрируйся на
_конкретных_ метаданных http-quiv.
> Никакой самый умный сервер за тебя ее не придумает.
http-quiv? "Умный сервер" должен уметь выдавать _все_ заголовки.
Т.е. _костыль_ в виде meta http-equiv _внутри_ html пользоваться не
должен.
> META - это не больше и не меньше, как способ задать
> такие данные в _HTML документе_. А еще можно в конфиге Апача.
Еще раз - я не говорю обо всех META. Я говорю конкретно о meta http-quiv.
> Тут все непонятно. Во-первых, ниоткуда не следует, что способ указывать
> метаданные где-то в конфиге сервера - самый правильный и единственно
> верный.
чуть ниже по тексту
=== cut ===
To sum up, conforming user agents must observe the following priorities when
determining a document's character encoding
(from highest priority to lowest):
1.An HTTP "charset" parameter in a "Content-Type" field.
2.A META declaration with "http-equiv" set to "Content-Type" and a
value set for "charset".
3.The charset attribute set on an element that designates an external
resource.
=== cut ===
Надеюсь не нужно объяснять что означает "from highest priority to lowest"?
> Мы уже выяснили, что и там и там можно задать чарсет более
> одного раза. Или еще как-то ошибиться.
Значит в отношении ошибки они критерии одного порядка, но в отношении
стандарта HTML4 - лучше задавать заголовки правильные.
> Рекомендация - это и есть рекомендация. Ну например Тутубалин так
> считает (на основе своего опыта). У других может быть другой опыт, и
> самое главное - другие потребности/условия. Поэтому от слов
> "правильный" - никакого толку. Надо добавлять в чем правильнее.
Добавлено. В _работе_.
> Вот я и пытался показать, в чем META может быть правильнее.
Достаточно узкий случай, который как показал Алекс - решается одним
скриптом :)
> > Обработку которой достаточно сложно реализовать в сервере.
> А ее вовсе не надо _на каждый запрос_ организовывать. Надо из META _один
> раз_ взять метаданные при обновлении документа, и потом _использовать_
> их при каждом запросе. Отпарсить документ вообще-то не сложно, если это
> часть процедуры upload страницы на сайт.
Вот, мне скажется что это должен делать вот тот самый, кто делает upload.
Видимо когда FrontPage/HomeSite/etc будут в полный рост работать через
mod_dav, и нужно будет колупать mod_dav на предмет (ок!) более эффективного
расположения метаданных.
[skip]
> > Так вот и решили, что лучше пользовать "другую часть стандарта",
> Кто решил, и для каких условий?
Для наиболее вероятных. Лично я такое решение поддерживаю, потоу как
_других_ условий у меня не возникает.
> Не люблю я такие решения, честно говоря.
> Предпочитаю свои выводы делать, ясно понимая, как и почему.
Дык, я тоже предпочитаю, только вот они поразительно совпали с
уже имеющимися.
> > правильно настроить сервер чтоб он отдавал всю информацию, правильно.
> Что значит "настроить"? Представь что у тебя сайт делают разные люди. В
> разных продуктах, разных ОС etc. В том числе - в разных кодировках, и в
> том числе - в пределах одного каталога. Что проще:
> - научить их правильно ставить META (это умеют практически все средства
> разработки), и написать скрипт, который при выкладывании файла на сайт
> использовал бы META, и сам генерировал .htaccess;
> - научить их же ставить кодировку где-то в .htaccess (а для этого
> сначала пустить их туда - и что они там направят)?
Мне сложно представить ситуацию ".... в пределах одного каталога".
_Всегда_ можно сделать еще одну ветку (например заменить cover.html
на cover/index.html), и "задача сводится к предидущей" :)
Bor.
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
