Re: [apache-rus] Vary (кажись, в самое время :)

["Khimenko Victor" <khim@sch57.msk.ru>]

In <374AE8E3.19CB6CE@escortcorp.com> Vladimir Pastukhov (vol@escortcorp.com) wrote:
VP> Khimenko Victor wrote:
>>
>> Как-то мне не нравится идея о ЛИНЕЙНОМ просмотре кучи файлов :-(( Может оно и
>> хорошо будет -- я не знаю, но просто как-то не нравится...

VP> Я не вижу другого решения, которое позволило бы не менять форматы
VP> данных сквида. Кроме того, ну сколько вариантов документа может
VP> находится в одном кэше (в нашем случае, т.е. различающихся по
VP> Accept-Charset)? Чаще всего не больше двух-трех, IMHO (в предлагаемом
VP> Вами варианте всегда будут просматриваться два файла).

Сколько ? Ну так с десяток наберется, я думаю. А то и с полсотни... Разные
browser'ы разную чушь туда суют (даже если они корректно настроены: мы же не
знаем, что на "Accept-Charset: iso-8859-5, unicode-1-1;q=0.8, iso-8859-10",
"Accept-Charset: iso-8859-5", "Accept-Charset: iso-8859-5, koi8-u" будет выдан
один и тот же ответ -- пока его не получим). То есть нам нужно учитывать, что
на разные запросы могут дать одинаковые ответы. И соотвественно организовывать
структуру. Опять же Etag пригодится :-)

>> В разных. В файле, соответствующем "непокореженному" url нужно хранить вместо
>> самой странички список вариантов. Все равно, конечно, будет линейный поиск,
>> но хоть в одном файле :-)

VP> Конечно, если делать по уму, а не на уровне хака, оно может быть
VP> и лучше, но тогда для начала неплохо бы договориться с командой
VP> сквида. Тут сразу возникнут вопросы о поддержании целостности кэша,
VP> ребилдах и бог знает что еще...

VP> Но только если делать "правильную" поддержку Vary, то все эти
VP> заголовки следовало бы пихать куда-нибудь в swap.state или
VP> вообще в отдельный (но один) файл и изменить алгоритм поиска.

Похоже, что нужно делать правильную поддержку: сделать за 2 часа хак не
удаётся, а если заняться этим серъезно, то можно и "как у людей" все сделать...

>> VP> слишком накладно, поэтому ну их нафиг. А проблема с ICP, по-видимому,
>> VP> решается только полным отказом от его использования :(
>>
>> Или его доработкой...

VP> А зачем, если есть HTCP, который для того и придуман? (но поддержку
VP> которого в сквиде, похоже, придется доделывать в любом случае)

Гм. Может быть в этом и есть своя сермяжная правда :-)) А HTCP все равно
придется доделывать -- в Squid'е он, похоже, Vary игнорирует...