#apache #http #browser-cache #cache-control
Вопрос:
Я столкнулся со странным поведением в chrome с http-запросами get, которые, скорее всего, имеют какое-то отношение к кэшу. В принципе, один и тот же запрос возвращает 200 в первый раз, затем, если я снова отправлю тот же запрос, снова введя строку URL, он вернет 404. Потом еще 200. Затем 404.
Запрос выглядит примерно так (с помощью инструментов разработки в chrome) Я использую##, чтобы скрыть конфиденциальную информацию
General:
Request URL: ###
Request Method: GET
Status Code: 200 OK
Remote Address: ##############
Referrer Policy: strict-origin-when-cross-origin
Response Headers:
Accept-Ranges: bytes
Cache-Control: max-age=0, no-cache
Content-Length: 75209
Content-Type: application/json
Date: Fri, 10 Sep 2021 10:29:22 GMT
ETag: W/"IDGfBPV6nmAIDGefDH3A0M"
Last-Modified: Wed, 08 Sep 2021 08:36:01 GMT
Server: Jetty(9.4.z-SNAPSHOT)
Request headers
Accept: text/html,application/xhtml xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7
Connection: keep-alive
Cookie: ##################
Host: #########
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
Если я сейчас снова нажму enter в строке URL, отправив запрос, я получу следующий ответ:
General
Request URL: ####
Request Method: GET
Status Code: 404 Not Found
Remote Address: ######
Referrer Policy: strict-origin-when-cross-origin
Response Headers
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 347
Content-Type: text/html;charset=iso-8859-1
Date: Fri, 10 Sep 2021 10:29:05 GMT
ETag: W/"IDGfBPV6nmAIDGefDH3A0M"
Server: Jetty(9.4.z-SNAPSHOT)
Request Headers
Accept: text/html,application/xhtml xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7
Cache-Control: max-age=0
Connection: keep-alive
Cookie: #################
Host: ####
If-Modified-Since: Wed, 08 Sep 2021 08:36:01 GMT
If-None-Match: W/"IDGfBPV6nmAIDGefDH3A0M"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
И так далее, 200, 404, 200, 404 …
Различия, которые я заметил, заключаются в заголовке управления кэшированием ответа и новых заголовках запроса, если они были изменены с тех пор, и Если они не совпадают.
Внутренний сервер является проприетарным сервером, а между клиентом находится прокси-сервер Apache.
Я знаю, что для получения решения я должен предоставить больше данных (возможно, конфигурацию httpd), но мне больше нравится пытаться понять, в чем проблема, а не просить волшебного решения.
Я поискал в Google «Get request работает и выключается» и всевозможные варианты формулировок, но мне не повезло.
Если бы кто-нибудь мог мне помочь, по крайней мере, понять проблему
Спасибо, Давид
Обновить
Как предположил Кевин в комментарии, отключение прокси-сервера apache не изменило это поведение включения/выключения. Должно быть что-то внутри исходного сервера
Комментарии:
1. Похоже, что-то неправильно обрабатывает условные запросы (т. Е. Запросы с
If-None-Match
). Первое, что нужно попробовать, это запустить его без прокси-сервера. Таким образом, вы узнаете, связана ли проблема с прокси-сервером или вашим исходным сервером.2. Спасибо Кевину за подсказку. Не должны ли условные запросы выдавать какую-то другую ошибку кода, а не 404? типа (304)
3. Да, они должны это сделать. Чтобы подтвердить, что это проблема, вы можете прекратить отправку
ETag
иLast-Modified
заголовки. Если все работает нормально, вы можете быть уверены, что проблема заключается в обработке условных запросов.4. Я использовал почтальона, чтобы отправить оба запроса (200 и 404). По — видимому, проблема заключается в значении параметра если совпадение отсутствует. (или вообще это условие). Если я удаляю заголовок if-non-match или связываю его с меткой etag правильного запроса, он работает.
5. Что вы имеете в виду, говоря «свяжите это с меткой правильного запроса»? В приведенном выше примере его сбоя связь верна (то есть
If-None-Match
второй запрос совпадаетETag
с первым ответом).