Chrome кэширует даже запросы HTTP DELETE

    Агрессивное кэширование контента браузером Chrome стало уже анекдотом и предметом головной боли веб-разработчиков. Насколько далеко готов зайти Chrome в кэшировании ресурсов? Ответ: очень далеко. Вплоть до того, что он даже запрос на удаление ресурса обрабатывает из кэша.

    Чтобы воспроизвести баг, нужно сначала отправить запрос к REST-сервису с кэширующим заголовком.

    Request URL: http://localhost:8888/files/cat.jpg
    Request Method: GET
    Status Code: 200 OK
    
    Response Headers
    Cache-Control:max-age=3600

    Следующий запрос на удаление ресурса:

    Request URL:http://localhost:8888/files/cat.jpg
    Request Method:DELETE
    Status Code:200 OK (from cache)

    В баг-трекере Chromium развернулась веселая дискуссия: говорят, будто Google не верит, что из интернета можно что-то удалить.
    Support the author
    Share post

    Similar posts

    Comments 60

      –25
      Никогда не пользовался HTTP DELETE. Подскажите сценарий использования
      +3
      Так может вебсервер отвечает not modified?
        +2
        На какой запрос?
          +3
          responce на запрос HTTP DELETE возвращает данные, которые not modified.

          10.3.5 304 Not Modified

          If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

          The response MUST include the following header fields:

          — Date, unless its omission is required by section 14.18.1
          If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

          — ETag and/or Content-Location, if the header would have been sent
          in a 200 response to the same request
          — Expires, Cache-Control, and/or Vary, if the field-value might
          differ from that sent in any previous response for the same
          variant
          If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

          If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

          If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

          Т.о. делаем простое предположение: application-server вернул 200, веб сервер вернул 304, хром увидел 304 и закешировал
          Логов веб сервера в тикете не видно, какой веб сервер и какие настройки не понятно.
            +1
            вместо «увидел и закешировал» «увидел и выдал из кеша»
              +1
              Да, но второй запрос ведь DELETE, а первый GET.

              Как можно отдавать результаты кеша другого запроса?
                0
                А где сказано, что это кеш первого запроса?
                То, что путь одинаковый, не означает, что одинаковые запросы.
                  +1
                  Я понимаю, что это не означает одинаковых запросов.

                  В тикете указаны условия воспроизведения проблемы. Основываясь на репорте я и сделал комментарий выше.

                  А именно: если сделать GET запрос к ресурсу, то потом DELETE запрос к тому же ресурсу будет отдан из кэша.

                  М?
                    +2
                    Request URL:http://0.0.0.0:3000/reports/10
                    Request Method:GET
                    Status Code:200 OK

                    Request URL:http://0.0.0.0:3000/reports/10
                    Request Method:GET
                    Status Code:304 Not Modified

                    Request URL:http://0.0.0.0:3000/reports/10
                    Request Method:DELETE
                    Status Code:200 OK

                    Ruby on Rails, dev environment
                    webrick web server
                      0
                      Response Headers
                      Cache-Control:max-age=3600
                      

                      Вы забыли про включенное кеширование на стороне сервера.
                        +1
                        Cache-Control:max-age=0
                        Я со стороны сервера приложений управляю кешированием.
                          0
                          Я не о том, вы говорите, что у вас ничего не повторяется. Для чистоты эксперимента надо было max-age оставить 3600, может тогда хром повел бы себя по-другому.
                            0
                            1. наличие или отсутствие кэша не зависит от срока жизни кеша
                            2. мне не нужен max-age, кеш или есть или его нет, средства веб сервера мне для этого не нужны
                            3. зачем пользоваться max-age? max-age на самом деле не знает когда точно объект является expired.
                      0
                      сервер приложений все 3 раза отвечал 200 Ок
                        +2
                        Я не понимаю о чём ваш комментарий. Я лишь повторил то, что есть в тикете.

                        Если вы считаете, что информация в тикете некорректная — то написать туда «вы ошибаетесь, всё работает так, как ожидается» будет эффективнее, чем сюда.

                        Я лишь говорю о том, что нааписано в репорте.
                          +3
                          Вы спросили «на какой запрос?», я дал вам исчерпывающий ответ, с экспериментом.
                          Они там и так знают, что эксперимент проведен с нарушениями. Я сам несколько раз выдел в коде php-разработчикв псевдо аттрибуты типа "_" => 9734985734957, для того чтобы Apache не кешировал запросы. Это трудности среды разработки, и к веб браузеру они не имеют никакого отношения.
                          Считайте, что это ответ на пост — «все работает так как ожидается»
                          А служба тех поддержки chrome боле меня осведомлена в попросах неожиданного поведения тех или иных сред разработки.
                            0
                            Это не служба поддержки chrome. В баг трекере отвечают разработчики chrome.
          0
          Мда. Для разработчиков это достаточно большая головная боль, когда были внесены изменения в js и css файлы а хром после многократных F5 отказывается изменения признавать.
            +1
            Достаточно просто в урл добавлять номер билда :-)
              +1
              В какой урл? Страницы открываемой дополнительный get параметр? Смысла тут нет, хром все закешировал. Скрипта? Это маразм, если ради каждой правки нужно будет править имя файла, а потом еще кучу мест его подключения. Речь, как правило, идет не о глобальный правках, а о правке пары строк в css. Вы что, заказчику вместо складных main.css, отдадите main-3.05.98.2004.css?
                0
                Нет, файлы и будут красивые, а вот урл будет перезаписываться вашим вебсервером.

                /assets//css/main.css -> /assets/css/main.css
                  +3
                  Парсер съел часть:

                  /assets/<build>/css/main.css -> /assets/css/main.css
                    –2
                    Т. е. из-за хрома делать надстройку на сервере, чтобы такие адреса обрабатывались? А если это виртуальный хостинг клиента, где нужно делать мелкие правки?
                    Да и от необходимости править шаблоны, где прописаны пути это не избавляет.

                    Чем устраивать такое, проче отказаться от хрома при разработке и проверять сайт под FF, например, а в хроме только на финальной стадии.
                      +3
                      Нет, не из-за хрома. А чтобы никогда ни с кем проблем не было.

                      Я решаю проблему так, как я описал.

                      Вы решаете — отказываясь от поддержки браузера.

                      У всех разные решения, я не настаиваю на том, чтобы вы стали делать как-то иначе.
                        +1
                        Не от поддержки хрома, а от разработки приложения с использованием хрома (для мониторинга результата).
                          0
                          Угу, уже понял что не умею внимательно читать.

                          ps: а такая проблема реально существует? Просто я как-то не сталкивался с излишне агрессивным кэшем хрома (при условии, что вебсервер корректные заголовки отдаёт)
                            0
                            Да, существует проблема. Программист сидит, отлаживает верстку, которая порезана на шаблон CMS. Что-то не так, он просит верстальщика поправить. Тот по фтп правит css, js, буквально пару строк.
                            А вот программисту, чтобы увидеть изменения еще как нужно извернуться, чтобы увидеть изменения. html то по F5 сбрасывается кеш. А вот все подключаемые файлы — нет. Он даже не запрашивает картинки, css и js и чтобы их сбросить нужно либо сбросить кеш совсем, либо открыть каждый файл напрямую в браузере и там нажать F5.
                            Поэтому разработчику не удобно пользоваться хромом.
                              +5
                              > А вот все подключаемые файлы — нет.

                              1. ctrl+f5
                              2. на продакшне нельзя ничего править
                              3. если хром кеширует файлы — значит этого попросил вэбсервер

                              В любом случае — это не проблема хрома.
                                +1
                                ctrl+f5 не срабатывает. Только раз эдак 20 если.

                                И это проблема хрома, так как в остальных браузерах ctrl+f5 работает на ура.

                                Опять же речь не о клиентах, а о программистах.
                                  0
                                  Хз, у меня всё нормально работает (и работало) :-S
                                    +2
                                    Во встроенных инструментах рзработчика можно кэш вообще отключить, если мешает сильно. Там настройка такая есть.
                                  0
                                  В настройках инспекторах Хрома есть пункт disable cache.
                                    0
                                    вот спасибо за дельный совет!
                                      0
                                      А я себе плагин Cache Killer поставил, как-то оно удобнее вск/выкл через кнопочку на панели кеш отключать, чем лазить в настройки…
                                    0
                                    F12 — Options — Disable cache.
                                    Второй вариант — два раза нажать Ctrl+R
                              +2
                              > А если это виртуальный хостинг клиента, где нужно делать мелкие правки?

                              Пардон за капитанство, но в продакшне вообще нельзя никаких правок вносить. А в случае с разработкой локально — можно билдить и перезаливать изменения.

                              > Да и от необходимости править шаблоны, где прописаны пути это не избавляет.

                              Не избавляет, но это автоматизируется
                              +1
                              Блин да вы прикалываетесь?
                              /css/main.css?build123
                                0
                                В чём принципиальная разница?
                                  0
                                  Избавляемся от совершенно ненужных rewrite-ов.
                                    0
                                    Это не «принципиальная» разница. Реврайт пишется 1 раз, и в отличие от текущего решения — урл становится «статическим»
                                      0
                                      Скажите это производительности апача :)
                                        0
                                        А есть какие-то проблемы с конкретно модреврайтом? Есть какие-то измерения, которые показывают, что апач без модреврайта сразу становится бодрячком?
                                          0
                                          Бодрячком он не станет из-за архитектуры, но каждый реврайт снижает производительность — факт.
                                            0
                                            Это снижение можно измерить? Очевидно, что немного ресурсов на него всё таки тратится, но действительно ли на фронтах всё всегда упирается в CPU и именно из-за модреврайта?
                              –2
                              Впечатление, что про ctrl+f5 никто не слышал…
                                +1
                                Клиенты не должны знать про ctrl+f5. Приложение должно работать вне зависимости от всяких ctrl+f5 ;-)
                                  +2
                                  Хром клал как на ctrl+f5, так и на f5 просто в случае если хочется сбросить кэш подключаемых файлов.
                                +2
                                > Это маразм, если ради каждой правки нужно будет править имя файла, а потом еще кучу мест его подключения.

                                Это всё должны делать билд-скрипты. Изменили что-то, сбилдили проект, отдали.
                                  +2
                                  При разработке сайта вообще могут не использоваться никакие билд скрипты, потому что они зачастую просто не нужны. Тем более при разработке на CMS. Верстальщик по фтп подправил строчку в css, и билд скрипт должен работать? Притом тут речь не о том, что сделали — отдали, а о том, что программист сидит, правит js, вносит изменения и смотрит результат, тестит, отлаживает, а у него они кешируются… Неужели на каждую правку новый билд создается? (а программист может до сотни раз скрипт пересохранять в ходе тестирования)
                                    –1
                                    Тогда ой

                                    PS: ни разу не встречался с тем, что хром кеширует данные, которые, согласно заголовкам вебсервера, кешировать не должен. Удивлён.
                                  0
                                  Добавляете в шаблон вместо прямой ссылки на css функцию, e.g.:
                                  add_css(«css_file_name»);
                                  Функция преобразует имя файла в /style/css/css_file_name.css?timestamp
                                  timestamp — время последнего изменения файла.
                                    0
                                    а в чем проблема собственно при подключении css указывать:
                                    main.css?3.05.98.2004?
                                  0
                                  Это не хром виноват, это ваш веб сервер считает эти данные идентичными. Если ваше приложение отдает эти файлы как идентичные веб серверу, то следует разборки устраивать между веб сервером и сервером приложений. Хром сдесь вообще не при делах.
                                    +1
                                    Я использую плагин Cache Killer. Когда отлаживаю верстку, нажимаю на кнопочку на панели инструментов, и кеш меня не беспокоит.
                                  • UFO just landed and posted this here
                                      +1
                                      Думаю если сервер явно не указывает поведение cache-control броузер волен кешировать как ему удобнее.
                                      Я во время разработки прописываю must-revalidate и хром отлично подгружает все изменения с сервера.
                                        +1
                                        мой хром поступает еще хуже: он запоминает изменения внесенные в css с помощью developer tools. обычный F5 не помогает. нужно только очистить кеш.
                                          +1
                                          Кэширует запросы HTTP DELETE это еще ладно, но почему он не отключает автозаполнение форм через HTTPS, когда этого требует сервер? Это в может привести к более плачевным последствиям…
                                          gayevoy.wordpress.com/why_autocomplete_doesnt_work_through_https_in_internet_explorer/
                                            0
                                            По ссылке не ходил, но есть мнение, что там речь идёт не о хроме.

                                          Only users with full accounts can post comments. Log in, please.