Кэширование заголовков, не тела, ЗАГОЛОВКОВ!
 

Вот ко мне закрадывается вопрос, ведь на генерацию заголовков, даже если ответ будет 302, все равно идет время, проверка заголовков, проверки.. и т.д. и т.п. , то есть, при любом ответе, заголовки будут всегда генерироваться, то бишь, при запросе одной и той же страницы, например, изображения, даже если оно закэшированное в браузере и выдаст нам потом 302, все равно сервер спросит у файла как минимум last modifed, сервер сразу же проверит ли существует файл, сервер проверит конфиг для этого типа файла, поставит нужный mime, сервер проверит ли используется сжатие, в конце концов(у меня) сервер создаст для всего этого отдельный объект с своими полями который будет генерировать эти заголовки. Так вот к чему мы приходим, совершенно не нужные(почти))) клиенту заголовки, будут генерироваться, но самое главное что это работа выполняется постоянно, при том что она однотипная, нужно ли всё-таки организовывать для этого некую штуку(кэш-заголовков), которая будет привязана к location(y) и сжатию(то есть идёт запрос на картинку, один браузер поддерживает сжатие gzip, а другой нет, и тогда будет два готовых заголовка), которая будет уже в себе имеет готовые заголовки для ответа? с возможностью сгенерировать нормальный ответ(если, например, тот же last modifed не совпадает с серверным), но при этом иметь некий дебагер, который будет работать в отдельном потоке и следить за этим кэшом-заголовков и сверять с действительностью(чтобы, если вдруг файл удалили, кэш-заголовка для этого файла заполниться сообщением про 404 ошибку)
Или же мне стоит добавить в кэш-документов, эти готовые заголовки, которые будут иметь пары значений, и при запросе будут смотреть какой запрос совпадает с первым значением и выдавать сразу второй, типа так:

file<index.html>
\index.html; accept-encoding: gzip; = <а тут готовый заголовок и сразу закэшированй файл>
\index.html; = <а тут готовый заголовок и файл>

Знаю, скорее всего, трудно понять эту ахинею, которую я написал, но в итоге вопрос, кэшируются ли заголовки?

Ну, вроде понял.

Не сталкивался с реализацией подобной идеи
Но, мне кажется, что
а) это экономия на спичках. Доля процессорного времени, приходящегося на генерацию заголовков существенно меньше, чем на выполнение серверных скриптов, или еще чего-нибудь.
Даже при отдаче мелкой статики, гораздо легче упереться в канал, чем в процессор(если использовать Nginx, конечно)
б) данное решение абсолютно негибкое, и труднонастраиваемое(если представить себе как мог бы выглядеть конфиг этой фичи)
В вашем примере клиенты с различными If-Modified-Since, или без оного получат одни и теже заголовки, хотя им даже код ответа должен прийти различный, в зависимости от актуальности клиентского кеша.
Учитывая, что практически все заголовки клиента несут ту или иную смысловую нагрузку, то во-первых получаем огромный кеш, в котором представлены ответы на любые комбинации клиентских заголовков, а во-вторых сложную логику, определяющую значимость заголовков(какие влияют на кеш, а какие нет), и правила обработки.
Получаемый монстр будет трудноподдерживаем программистом, и скорее всего медленнее работать, чем нормальный вариант(хотя бы из-за огромного кеша, по которому еще надо искать)


В итоге, получаем сложную фичу, которая может даже замедлить проект, и заставить пожирать память как стадо слонов.
Но, даже, если данная фича будет экономить ресурсы, то это будут доли процентов.
Усложнение же логики конфигов из-за такиой экономии - непропорционально для того, чтобы эту задачу кто-то реализовывал бы, ИМХО.

В общем, навряд ли это где-то есть, но если есть, то на это стоит взглянуть =)

Я почти реализовал через такую схему. У нас в кэше есть файлы, к каждому файлу привязан массив данных о нём, в него входят: массив файла, последнее изменение фала, дата добавления, размер, сжат ли он в кэше. К этим данным мы привязываем хеш заголовка запроса, хеш генерируется из параметров запроса, которые могут влиять на ответ(сжатие, ласт модифед, метод), но так же к этому хешу мы добавляем число, которое указывает на индекс добавленных заголовков ответа, в кэше, то есть к файлу добавляются вот такие строки:

hash_requst+"#"+index_ready_resp

де hash_requst это, например, вот такой хеш:
String hash_requst = HASH.MD5(requs.getHeader("Accept-Encoding")+requs.getHeader("If-Modified-Since"));

а index_ready_resp, это индекс который мы получим при добавлении в кэш готовых заголовков:
int index_ready_resp = serverManage.docCache.add(SERVER_RESPONSE,file_nam e);

Потом при запросе ищем файл в кэше, потом проверяем ли есть вообще хешы запросов для файла, если есть, то генерируем хеш текущего запроса и сверяем с теми что имеем с кэша, если находим нужный, берем вторую часть строки, то бишь, индекс, и обращаемся к кэшу для полученния готовых заголовков. Но тут есть косяк, мы не знаем надо ли потом выдать ещё файл, или сжатий файл, или вообще ничего, получается нам потом надо работать с готовыми заголовками что бы это узнать, то есть все равно хунта))

Можно по-другому, соединить полностью кэш файлов и заголовков, то есть иметь готовый ответ для различных запросов. Некое подобие ХешМапы, то есть значению хеша будет отвечать готовый результат, с телом, полностью, но для такого тогда надо полностью переделать очень большой кусок моей системы, но при этом выгоду от такой схемы можно поиметь только при ОЧЕНЬ ВЫСОКИХ нагрузках, и то за счёт ОЗУ. И при этом, надо иметь возможность отключения такой системы, чтобы сервер имел гибкость, а так же всёравно должен быть отдельный поток который будет работать с этим кэшом, обновлять, очищать, добавлять. То есть система должна быть автономной и саморегулируемой, чтобы сервер сам, при больших нагрузках, создавал готовые ответы для файлов с низким интервалом запросов, а когда интервал между запросами для файла увеличивается, то система его очищала его из кэша, у меня сейчас такая система уже работает но она кэшурует и работает только с файлами, то есть с телом ответа, но стоить всё-таки к ней добавлять заголовки?...

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

Немного переделал, просто у меня плохо с письмом, но вы говорите где промахи, буду исправлять)