Как знать, когда отправить 304 Не Измененный ответ
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
5 ответов
Вот то, как я реализовал его. Код работал некоторое время больше чем год и с несколькими браузерами, таким образом, я думаю, что это довольно надежно. Это основано на RFC 2616 и путем наблюдения, какой и когда различные браузеры отправляли.
Вот псевдокод:
server_etag = gen_etag_for_this_file(myfile)
etag_from_browser = get_header("Etag")
if etag_from_browser does not exist:
etag_from_browser = get_header("If-None-Match")
if the browser has quoted the etag:
strip the quotes (e.g. "foo" --> foo)
set server_etag into http header
if etag_from_browser matches server_etag
send 304 return code to browser
Вот отрывок моей логики сервера, которая обрабатывает это.
/* the client should set either Etag or If-None-Match */
/* some clients quote the parm, strip quotes if so */
mketag(etag, &sb);
etagin = apr_table_get(r->headers_in, "Etag");
if (etagin == NULL)
etagin = apr_table_get(r->headers_in, "If-None-Match");
if (etag != NULL && etag[0] == '"') {
int sl;
sl = strlen(etag);
memmove(etag, etag+1, sl+1);
etag[sl-2] = 0;
logit(2,"etag=:%s:",etag);
}
...
apr_table_add(r->headers_out, "ETag", etag);
...
if (etagin != NULL && strcmp(etagin, etag) == 0) {
/* if the etag matches, we return a 304 */
rc = HTTP_NOT_MODIFIED;
}
Если Вы хотите некоторую справку с сообщением поколения завершающего тега другой вопрос, и я откопаю некоторый код, который делает это также. HTH!
относительно управления кэша:
Вам не придется волноваться об управлении кэша при раздавании кроме установки его к рыночной стоимости. Это в основном говорит браузер и другие нисходящие объекты (такие как прокси) максимальное время, которое должно протечь прежде, чем привести к таймауту кэша.
Необходимо отправить 304, если клиент явно заявил, что это может уже иметь страницу в своем кэше. Это называют, условное выражение ДОБИРАЮТСЯ, который должен включать if-modified-since заголовок в запрос.
В основном этот заголовок запроса содержит дату, с которой клиент утверждает, что имел кэшируемую копию. Необходимо проверить, изменилось ли содержание после этой даты и отправляет 304, если это не имеет.
См. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 для связанного раздела в RFC.
304 Не Измененный ответ могут следовать из ПОЛУЧЕНИЯ или ВОЗГЛАВИТЬ запрос или с If-Modified-Since ("IMS") или с If-Not-Match ("INM") заголовок.
Для решения, что сделать, когда Вы получаете эти заголовки, предполагаете обработку ПОЛУЧИТЬ запроса без этих условных заголовков. Определите то, чем значения Вашего Завершающего тега и Измененных в последний раз заголовков были бы в том ответе и использовали бы их для принятия решения. Надо надеяться, Вы создали свою систему, таким образом, что определение этого является менее дорогостоящим, чем построение полного ответа.
Если бы существует INM, и значение того заголовка совпадает со значением, которое Вы поместили бы в Завершающий тег, то ответили бы 304.
Если бы существует IMS, и значение даты в том заголовке позже, чем тот, который Вы поместили бы в Измененный в последний раз, то ответили бы 304.
Еще, продолжите двигаться, как будто запрос не содержал те заголовки.
Поскольку наименьшее-количество-усилие приближается к части 2 Вашего вопроса, фигура, которую из (Истекает, Завершающий тег, и Измененный в последний раз) заголовки можно легко и правильно произвести в веб-приложении.
Для предложенного материала чтения:
Мы также обрабатываем кэшированные, но защищенные ресурсы. Если вы отправляете / генерируете заголовок ETAg (который СЛЕДУЕТ вам в разделе 13.3 RFC 2616), то клиент ДОЛЖЕН использовать его в условном запросе (обычно в заголовке If-None-Match - HTTP_IF_NONE_MATCH). Если вы отправляете заголовок Last-Modified (опять же, ОБЯЗАТЕЛЬНО), вы должны проверить заголовок If-Modified-Since - HTTP_IF_MODIFIED_SINCE -. Если вы отправляете оба, то клиент ДОЛЖЕН отправить оба, но он ДОЛЖЕН отправить ETag. Также обратите внимание, что валидация просто определяется как проверка условных заголовков на строгое равенство с теми, которые вы отправляете. Кроме того, только надежный валидатор (например, ETag) будет использоваться для запросов с диапазоном (когда запрашивается только часть ресурса).
На практике, поскольку ресурсы, которые мы защищаем, довольно статичны, и время задержки в одну секунду является приемлемым, мы делаем следующее:
Проверяем, имеет ли пользователь право доступа к запрошенному ресурсу
Если нет, перенаправьте его или отправьте ответ 4xx в зависимости от ситуации. Мы сгенерируем 404 ответа на запросы, которые выглядят как попытки взлома или вопиющие попытки выполнить завершающий запуск безопасности.
Сравните заголовок If-Modified-Since с заголовком Last-Modified, который мы отправили бы (см. Ниже) для строгого равенства
Если они совпадают, отправьте ответ 304 Not Modified и завершите обработку страницы
Создайте заголовок Last-Modified используя время модификации запрошенного ресурса
Найдите формат даты HTTP в RFC 2616
Отправьте заголовок и содержимое ресурса вместе с соответствующим Content-Type
Мы решили отказаться от заголовка ETag, поскольку он перебор для наших целей. Я полагаю, мы могли бы также использовать метку даты и времени в качестве ETag. Если мы перейдем к настоящей системе ETag, мы, вероятно, будем хранить вычисленные хэши для ресурсов и использовать их как ETags.
Если ваши ресурсы генерируются динамически, например, из содержимого базы данных, то ETags могут быть лучше для ваших нужд, поскольку они являются просто текстом, который нужно заполнить по своему усмотрению.