Как знать, когда, чтобы отправить 304 Not Modified ответ

голоса
10

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

  1. Какие окончательные HTTP заголовки, которые мне нужно проверить, чтобы знать наверняка, должен ли я отправить 304 ответ, и то, что я ищу, когда я проверить их?

  2. Кроме того, есть ли заголовки, которые мне нужно отправить, когда я сначала отправить файл (например, «Last-Modified») как 200 ответ?

Некоторый псевдо-код, вероятно, будет наиболее полезным ответом.


Как насчет заголовка кэш-контроля? Могут ли различные возможные значения, которые влияют на то, что вы отправляете клиенту (а именно максимального возраста) или следует только в том случае, Modified-Since повиноваться?

Задан 07/08/2008 в 08:54
источник пользователем
На других языках...                            


5 ответов

голоса
8

Вот как я реализовал его. Код работает на чуть больше года , и с несколькими браузерами, поэтому я думаю , что это довольно надежный. Это основано на RFC 2616 и наблюдая , что и когда различные браузеры посылали.

Вот псевдокод:

server_etag = gen_etag_for_this_file (MyFile)
etag_from_browser = get_header ( "Etag")

если etag_from_browser не существует:
    etag_from_browser = get_header ( "If-None-Match")
если браузер процитировал ETag:
    раздеть кавычки (например, "Foo" -> Foo)

Набор server_etag в заголовке HTTP

если etag_from_browser соответствует server_etag
    отправить 304 код возврата в браузер

Вот отрывок из моей логики сервера, который обрабатывает это.

/ * Клиент должен установить либо Etag или If-None-Match * /
/ * Некоторые клиенты процитировать PARM, стрип кавычки, если так * /
mketag (ETag, & SB);

etagin = apr_table_get (г> headers_in, "Etag");
если (etagin == NULL)
    etagin = apr_table_get (г> headers_in, "If-None-Match");
если (ETag! = NULL && ETag [0] == '"') {
    ИНТ сл; 
    SL = StrLen (ETAG);
    memmove (ETag, ETag + 1 сл + 1);
    ETag [SL-2] = 0;
    логит (2, "= ETag:% s:", ETag);
}   
... 
apr_table_add (r-> headers_out, "ETag", ETag);
... 
если (etagin! = NULL && зЬгстр (etagin, ETag) == 0) {
    / * Если ETag совпадает, мы возвращаем 304 * /
    гс = HTTP_NOT_MODIFIED;
}   

Если вы хотите некоторую помощь Etag пост поколения еще один вопрос, и я выкопать некоторый код, который делает это, как хорошо. НТН!

Ответил 07/08/2008 в 09:30
источник пользователем

голоса
4

304 Not Modified реакция может быть результатом запроса GET или HEAD, либо с If-Modified-С ( "IMS") или заголовка If-Not-Match ( "ИВМ").

Для того, чтобы решить, что делать, когда вы получите эти заголовки, представьте, что вы регулируете запрос GET без этих условных заголовков. Определите, какие значения вашего ETag и Last-Modified заголовки будут в этой связи и использовать их, чтобы принять решение. Надеюсь, вы построили свою систему таким образом, чтобы определить это является менее дорогостоящим, чем построение полного ответа.

Если есть INM и значение этого заголовка является такой же, как значение, которое вы бы место в ETag, а затем реагировать с 304.

Если есть IMS и значение даты в этом заголовке позже, чем тот, который вы бы место в прошлом-Modified, а затем реагировать с 304.

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

Для наименее усилию подхода к части 2 вашего вопроса, выяснить, какие из (Expires, ETag, и Last-Modified) заголовки Вы можете легко и правильно произвести в вашем веб-приложении.

Предлагаемое материала для чтения:

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://www.mnot.net/cache_docs/

Ответил 09/08/2008 в 14:27
источник пользователем

голоса
3

Вы должны отправить 304 , если клиент четко указано , что он уже может иметь страницу в своем кэше. Это называется условный GET, которая должна включать в себя, если-Modified-Since заголовка в запросе.

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

См http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 для соответствующего раздела в RFC.

Ответил 07/08/2008 в 09:01
источник пользователем

голоса
2

Мы также погрузо-кэшируются, но обеспеченные, ресурсы. Если вы отправляете / генерировать заголовок Etag (который RFC 2616 раздел 13.3 рекомендует вам нужно), то клиент должен использовать его в условном запросе (обычно в If-None-Match - HTTP_IF_NONE_MATCH - заголовок). Если вы отправляете Last-Modified заголовок (опять же вы должны), то вы должны проверить If-Modified-Since - HTTP_IF_MODIFIED_SINCE - заголовок. Если вы посылаете как, то клиент должен послать обоих, но он должен отправить ETag. Также отметим, что validtion просто определяется как проверка условных заголовков для строгого равенства в отношении тех, кого вы бы отсылают. Кроме того, только сильный валидатор (например, ETag) будет использоваться для дистанционных запросов (где только часть ресурса запрашивается).

На практике, поскольку ресурсы, мы защищаем довольно статичны, и один второй временной лаг является приемлемым, мы делаем следующее:

  1.  Проверьте, чтобы увидеть, если пользователь имеет право доступа к запрошенному ресурсу

         Если они не являются, перенаправлять их или отправить ответ 4xx в зависимости от обстоятельств. Мы будем генерировать 404 ответов на запросы, которые выглядят как попытки взлома или вопиющими пытается выполнить концевые безопасности запуска.

  2.  Сравнить If-Modified-Since заголовка на Last-Modified заголовка мы послали бы (см ниже) для строгого равенства

         Если они совпадают, то отправить 304 Not Modified ответ и выход страницы обработки

  3.  Создание Last-Modified заголовка, используя время модификации запрошенного ресурса

        Посмотрите формат HTTP Даты в RFC 2616

  4.  Разошлите содержание заголовка и ресурсов наряду с соответствующим Content-Type

Мы решили отказаться от заголовка ETag, так как это слишком для наших целей. Я полагаю, мы могли бы просто использовать временную дату штампа в качестве ETag. Если мы перейдем к истинной системе ETag, мы, вероятно, хранить вычисленные хэш для ресурсов и использовать их в качестве ETags.

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

Ответил 13/10/2009 в 15:05
источник пользователем

голоса
1

о кэш-контроль:

Вы не должны беспокоиться о кэш-контроля при обслуживании вне, кроме установки его в разумных пределах. Это в основном говорит браузер и другие нижестоящие объекты (например, доверенность) максимальное время, которое должно пройти, прежде чем таймаут кэша.

Ответил 07/08/2008 в 09:47
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more