Я завершил небольшое приложение PHP, которое может обслуживать многие документы. Эти документы должны кэшироваться клиентами и прокси.
Поскольку прокси-серверы могут кэшировать мои результаты, я должен быть особенно осторожным, потому что у документов, которые я обслуживаю, могут быть разные типы MIME (согласование контента на основе $ _SERVER ['HTTP_ACCEPT']) и разные языки (в этом порядке: значение $ _POST / $ _GET / URL / значение сеанса PHP / $ _COOKIE value / $ _SERVER ['HTTP_ACCEPT_LANGUAGE'] / значение сценария по умолчанию).
Короче говоря, страница может обслуживаться со многими типами MIME и многими языками с одинаковым URL (вопрос изменился: см. Ниже).
Чтобы помочь кешировать прокси, я использую заголовок «Vary: Accept» в сочетании с заголовком ETag. ETags – это MD5 текущего языка и последняя измененная метка времени.
Я всегда:
Теперь с моим вопросом: достаточно ли этого, чтобы помочь кешировать прокси и клиентов? Я пропустил предмет / заголовок?
Чтобы помочь вам, вот заголовок ответа HTTP для тестовой страницы (в моей локальной среде):
" Date Wed, 30 Dec 2009 18:56:26 GMT Server Apache/2.0.63 (Win32) PHP/5.1.0 X-Powered-By PHP/5.1.0 Set-Cookie Tests=697daqbmple2e1daq2dg74ur96; path=/ Expires Wed, 30 Dec 2009 21:56:26 GMT Cache-Control public, max-age=10800 Last-Modified Mon, 28 Dec 2009 15:11:49 GMT Etag "44fa50be4638161a596e4b75d6ab7a94" Vary Accept Content-Language en-us Content-Length 3043 Keep-Alive timeout=15, max=100 Connection Keep-Alive Content-Type application/xhtml+xml; charset=UTF-8 " EDIT: ОК. Я понимаю, что в этом случае обслуживание документа со многими MIME и наличие разных языков (которые могут исходить из стольких источников – см. Выше) – это просто плохая конструкция. Если вы хотите сделать это, просто используйте «частный» кеш (без кеша на прокси) … Правильно ли?
Если у каждого языка есть собственный URL-адрес (но каждый URL-адрес может обслуживаться со многими MIME-файлами), моя текущая реализация в порядке для «общего» кеша (кеш на клиентах + прокси)?
Поскольку ваш результат также зависит от того, что прокси-сервер не может знать как данные сеанса, не будет ли проще отправлять (не-кэшируемые) перенаправления на фактический контент, который будет исправлен для заданного URL (с параметрами), и, следовательно, много легче кэшировать. Я знаю, что это связано с дополнительным кругосветным путешествием, но это, вероятно, гораздо менее подвержено ошибкам, а также вызывает меньше проблем с прокси-серверами, которые не полностью понимают / поддерживают все ваши комбинации заголовков.
Кроме того, я предполагаю, что если у вас есть два клиента, проходящих через один и тот же прокси, но с разными языковыми кукисами, ваш текущий метод вернет два разных ETags для одного и того же URL-адреса, что сделает прокси-сервер обновлять его копию каждый раз, когда он видит другого клиента.
Я считаю, что в принципе вы должны быть в порядке: добавление заголовка Vary означает, что кеши должны содержать несколько экземпляров ваших данных, с помощью ETag.
Я бы отметил, однако, что вы не только меняетесь на Accept, но и на Cookie и Accept-Language. Варьирование cookie означает, что прокси должен будет проверять каждый запрос, но должен иметь возможность использовать заголовок If-None-Match, чтобы сервер указывал, какой (уже кэшированный) ETag следует использовать.
Если ответ меняется как на «Accept», так и «Accept-Language», то оба они должны упоминаться в заголовке ответа «Vary».