ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-talk] =?koi8-r?B?UmVbMl06IFthcGFjaGUtdGFsa10gUmU6IFthcGFjaGUtdGFsa10gUmU6ICDt?==?koi8-r?B?zs/Hz9Ha2d7O2cogKCBtdWx0aWxpbmd1YWwpICDTwcrU?=




Hello!

27.02.03, 11:12, you wrote:

>> Может все-таки это оставить на совесть админа.

AT> Проблема заключается в том, что совесть админа должна вступить в астральную
AT> коммуникацию с админами всех (потенциальных) транзитных proxy (поисковики
AT> в этом контексте не так интересны)

Если не "вступит" - то это будет проблема его конкретного сайта.

>> Например у меня сайт, совсем не нуждается в поисковиках
>> - это платежный шлюз, и абсолютно _все_ страницы сугубо индивидуальны для
>> каждого пользователя.
AT> Так уж и все.

Абсолютно.

AT> А головная страница, а новости, а пресс-релизы ?

Нету. Ни новостей, ни пресс-релизов,
для этого отдельный сайт со статикой,
а меня волнует сам инструмент.

AT> А те которые индивидуальны - все-равно выдаются персонально после
AT> авторизации - и в параметрах пользователя кроме баланса счета можно
AT> иметь и язык.

Не совсем, там авторизация не проходит,
страница формируется в зависимости от переданных параметров,
да там иногда присутствует язык.

Я наверное не совсем понятно описал свою проблему.
Она чуть отличается от того с чего мы начали обсуждение.

Попробую еще раз.

Выдается страница на _выбранном_ (не важно как) языке.

Апач перекодирует содержание из ИСХОДНОЙ кодировки (основываясь на
конфиге) в ВЫХОДНУЮ (основываясь на клиенте, например).

Так вот проблема в том что для разных языков - ИСХОДНАЯ кодировка
- разная.

Как быть в таком случае?

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

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

Можно конечно.
Но не хочется скрипты этим загружать,
хотя чувствую придется...

>> Это кодировка запроса, а кодировка ответа наверное может отличаться...
>> Или это идеологически не верно?
AT> Может. Но откуда вы знаете, что клиент ее поймет.

Если пользователь попросил такой язык,
то пусть получает чего просил...
Хотя в других каких-то языках,
то существует несколько кодировок...
- придется много таблиц делать...

Кстати вопрос к гуру перекодировки:

- Все ли кодировки платформенно-специфичны?

>> Хотя сейчас наверное можно клиенту указывать в какой кодировке у тебя
>> ответ, но тогда и клиент будет передавать запрос в своей родной
>> кодировке, не так ли?
AT> Клиенты - разные. В MSIE есть мощный искусственный интеллект, которого

Но если указать в заголовке кодировку - MSIE - покажет именно в
указанной, isn't it?

>>> >Не, у разных версий должны быть разные адреса.
>>> >
>> Если это статика - то да.
AT> Это может быть "псевдостатика"

Ну да, псевдостатика - тоже статика,
имею ввиду динамика - разная на каждый сеанс.

AT> То-есть контент одного URL может меняться (за короткое время) только
AT> если приняты все меры по не-кэшированию. Так как эти меры обычно
AT> мучительны для клиента (back-forward перестают нормально работать, 
например),

Не всегда кэширование хорошо.
Например когда страница содержит что-то важное,
а пользователь лазит из интернет-кафе...

AT> то "настоящая динамика" должна, IMHO, выдаваться с чем-то уникальным в URL
AT> (случайное число и т.п.)

Технически - это да.

Но пользователя пугает когда у УРЛе есть что-то неподдающиеся
логическому пониманию.

Vale!

-- 
Alexander (Thor) Ivashchenko



 




Copyright © Lexa Software, 1996-2009.