Предлагаю для решения этой проблемы сделать следующее.
1. Если в заголовке ответа есть одно из:
Pragma: no-cache
Cache-control: no-store
Cache-control: private
и включена опция Игнорировать No-cache, при формировании пути файла в кэше добавлять имя пользователя и получится что-то такое:
c:\handycache\cache\vasja_pupkin\mail.ru\...
Если опция Игнорировать No-cache выключена, такие файлы не писать вообще.
2. Дать возможность в списке Преобразование URL в колонке Замена использовать переменную #user#. Писать, например, так  #user#\1. При этом #user# будет заменяться на vasja_pupkin\
3. При поиске файла в кэше искать файлы сначала в персональной папке, а при неуспехе в общей. Это, конечно, увеличит нагрузку на диск, но не катастрофически. Чего не сделаешь ради соблюдения приватности.

---

  В HC версии 1.0 RC2 (1.0.0.175) от 27.05.2009 г. в списке "Преобразование URL" в колонке Замена можно использовать подстановку #user#. При выполнении преобразования вместо #user# будет подставлена стока 'user_name/', где user_name - имя пользователя, чей запрос обрабатывается.

В п.1 я собрал все способы, которыми, по моему мнению, сервер может пометить приватную информацию, дабы предотвратить ее всеобщую доступность. Стандартным поведением прокси должно быть обеспечение этой приватности. Все отклонения от стандартного поведения могут быть обеспечены скриптами, правилами и чем угодно еще.
Откуда же НС узнает, что нужный ему файл подпадает под "приват"? Ему придется искать в обоих частях кэша пока не найдет.

Личных наблюдений по использованию no-cache и no-store у меня нет. У меня есть в chm книжечка
HTTP Developer's Handbook
By Chris Shiflett
   
Publisher : Sams Publishing
Pub Date : March 21, 2003
ISBN : 0-672-32454-7
Pages : 312
Вот в ней про поле Cache-control написано
И про Pragma: no-cache

Добавлено: 03 Августа 2008, 12:40:08

На мой взгляд поведение прокси дожно быть безопасным по умолчанию, без использования специальных правил или скриптов.
Добавлено: 03 Августа 2008, 12:50:41

Так ведь могут же, значит это должно быть учтено стандартным поведением.

Автоматически отличить "приват" от "паблика" так не получится. На каждом сайте у него могут быть свои отличительные признаки, т.к. слово "private" сервера вставляют в заголовки далеко не всегда. На многих сайтах "приват" можно отличить только по URL. Так, например, на ру-борде любые страницы (даже для "Гостей") сервер отдает с заголовками:
И, следовательно, если смотреть на "no-cache", то каждый пользователь будет качать страницы форума заново, хотя мог бы спокойно взять их из общего кэша.

ИМХО, пользователь (админ) должен иметь возможность тонко настроить, что по его мнению является приватом, а что можно выложить в общий доступ.


А вот это, пожалуй, единственный на данный момент способ для выделения привата. Сработало "приватное" правило - кэшируем в персональной папке, не сработало - в общей. На заголовки пока не смотрим, т.к. хранить признак "привата" все равно негде.


Искать в двух папках не придется, если опираться только на правила в "Преобразовании URL".

Set-Cookie есть на многих сайтах, даже где вообще нет авторизации! Куки часто используются просто для сбора статистики, сохранения настроек сайтов и т.п.

В общем, это плохой критерий приватности данных!

P.S. Если желаешь вообще не кэшировать страницы, где есть заголовок Set-Cookie, то это уже сейчас можно сделать скриптом Lua.

Проблема в том, что четкого критерия приватности кроме неполуярного "Cache-control: private" не существует. А отнесение к привату всех данных с заголовками "Pragma: no-cache" и "Cache-control: no-cache, no-store" похерит большую часть общего публичного кэша, что скажется не только на экономии трафика, но и нагрузке на диск, которая в данный момент является узким местом программы и без того близка к критической!


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