Уточнения к группе задач "кэширующий прокси"

Прокси должен удовлетворять следующим требованиям:

1. Должен поддерживаться HTTP 1.0. Прокси должен корректно информировать как клиента, так и сервер об используемой версии протокола
2. Клиенты и серверы HTTP 0.9 (даже если таковые удастся найти) могут не поддерживаться, т.е. прокси может отказываться работать с ними, либо работа с ними может осуществляться в режиме HTTP 1.0. Возникающие при этом проблемы не являются основанием для отказа в приеме задания.
3. Поддержка HTTP 1.1 не обязательна. Поддерживать персистентные соединения 1.1 не требуется.
4. Необходимо поддерживать операцию GET. Поддержка всех остальных операций опциональна; отказ поддерживать остальные операции не является основанием для отказа в приеме задания. Ответы на операцию PUT, если сама эта операция будет реализована, кэшировать не следует.
5. Кэшировать надлежит только ответы типа 200 (нормальная передача страницы). Все остальные ответы следует передавать браузеру без изменений и кэшировать не следует.
6. Кэшировать следует как текстовые, так и бинарные ресурсы, с обязательным сохранением MIME типа ресурса.
7. Кэш хранится в памяти и может полностью теряться при перезапуске прокси.
8. Обработка полей заголовка, управляющих кэшированием, таких, как last modified и pragma no cache, не обязательна. Некорректная работа сайтов с динамическим HTML, обусловленная некорректной обработкой этих параметров, не является основанием для отказа в приеме задания.
9. Поддержка cookies не обязательна. Некорректная работа сайтов, использующих cookie (в том числе и для авторизации) не является основанием для отказа в приеме задания
10. Поддержка любых механизмов авторизации на сайтах не обязательна. Проверяется только корректность анонимного доступа.
11. Допускается как самостоятельная реализация анализа заголовка HTTP, так и использование third-party библиотек парсеров заголовка.
12. Допускается использование языков C и C++
13. Все варианты задания предполагают параллельную обработку запросов, т.е. при тестировании необходимо продемонстрировать возможность открыть несколько клиентских сессий и показать, что ни одна из сессий не ждет завершения операции ни одной из других сессий.
14. Псевдомногопоточная реализация и реализация с пулом потоков не должны иметь ограничений по количеству клиентских сессий (кроме количества дескрипторов открытых файлов). Т.е. обе эти реализации обязаны поддерживать больше сессий, чем имеется потоков в пуле. В этом смысле, псевдомногопоточную реализацию можно рассматривать как вырожденный случай пула потоков.
15. Допускается сдача пула потоков с объемом пула, равным 1, в качестве псевдомногопоточной реализации. В этом случае, преподаватель имеет право потребовать удалить из кода все примитивы pthread (возможно, при помощи конструкции #ifdef) и продемонстрировать сборку и работу приложения без использования libpthread.
16. Простая многопоточная реализация имеет право отвергать или задерживать входящие соединения при невозможности создать новый поток.
17. Если две клиентские сессии скачивают одну и ту же страницу, необходимо, чтобы обе сессии работали с одной и той же записью кэша, понимали, что запись неполная и адекватно реагировали на докачку.
18. Прокси должен корректно обрабатывать сброс клиентских сессий. В том числе, в случае, когда две или более сессий работали с одной записью кэша, после сброса одной из них, остальные сессии должны корректно продолжить докачку страницы.
19. Допускается создание двух нитей на каждое клиентское соединение: "клиентская" нить обрабатывает соединение с клиентом, "серверная" - с сервером. При работе двух клиентских сессий с одной записью кэша при этом следует создавать две клиентские нити, но одну серверную. При передаче клиенту полной записи кэша, серверную нить можно не запускать. В случае пула потоков, допускается разделение пула на два, серверных и клиентских нитей, исполняющих разный код. Первый студент в группе, сдавший такую реализацию, получает бонус - ему засчитывается одна "простая" задача.
20. При сбросе единственной сессии, работавшей с записью кэша, допускается как сброс докачки страницы и уничтожение записи в кэше, так и фоновое продолжение докачки. Преподаватель имеет право потребовать изменения стратегии обработки этой ситуации, т.е. потребовать переделать сброс докачки на ее фоновое продолжение или наоборот (это может быть полезно для проверки корректности управления записями в кэше).
21. Допускается также обработка сброса сессии в форме сохранения в кэше неполной записи. При повторном обращении к этой записи необходимо запустить докачку страницы командой REGET; необходимо также корректно обработать ситуацию, когда сервер эту команду не поддерживает. Первый студент в группе, сдавший такую реализацию, получает бонус: ему засчитывается одна "простая" задача.
22. Использование явных и неявных холостых циклов для синхронизации потоков не допускается. Допускается использование стандартных примитивов синхронизации pthread, системных вызовов select и poll и вызовов асинхронного ввода-вывода.
23. В частности, высокая загрузка процессора (по показаниям top) при малой активности соединений интерпретируется как явный или неявный холостой цикл и является основанием для отказа в приеме задания. При обнаружении такого поведения, преподаватель имеет право потребовать доказательства корректности используемой схемы синхронизации.
24. Трудновоспроизводимые "глюки" при работе прокси интерпретируются как ошибки соревнования, и являются основанием для отказа в приеме задания. После обнаружения таких "глюков" преподаватель имеет право потребовать доказательства корректности используемой схемы синхронизации.
25. Допускается сдача подсистем прокси в качестве отдельных "простых" заданий. Студент сам должен понять, какие подсистемы могут быть сданы в качестве каких заданий. Необходимо продемонстрировать, что подсистема компилируется (возможно, с #ifdef'ами) и работает в виде самостоятельной программы. Сдача подсистем и целого прокси может производиться в любом порядке.