Comments 60
Никогда не пользовался HTTP DELETE. Подскажите сценарий использования
Так может вебсервер отвечает not modified?
На какой запрос?
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 и закешировал
Логов веб сервера в тикете не видно, какой веб сервер и какие настройки не понятно.
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 и закешировал
Логов веб сервера в тикете не видно, какой веб сервер и какие настройки не понятно.
вместо «увидел и закешировал» «увидел и выдал из кеша»
Да, но второй запрос ведь DELETE, а первый GET.
Как можно отдавать результаты кеша другого запроса?
Как можно отдавать результаты кеша другого запроса?
А где сказано, что это кеш первого запроса?
То, что путь одинаковый, не означает, что одинаковые запросы.
То, что путь одинаковый, не означает, что одинаковые запросы.
Я понимаю, что это не означает одинаковых запросов.
В тикете указаны условия воспроизведения проблемы. Основываясь на репорте я и сделал комментарий выше.
А именно: если сделать GET запрос к ресурсу, то потом DELETE запрос к тому же ресурсу будет отдан из кэша.
М?
В тикете указаны условия воспроизведения проблемы. Основываясь на репорте я и сделал комментарий выше.
А именно: если сделать GET запрос к ресурсу, то потом DELETE запрос к тому же ресурсу будет отдан из кэша.
М?
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
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
Response Headers
Cache-Control:max-age=3600
Вы забыли про включенное кеширование на стороне сервера.
сервер приложений все 3 раза отвечал 200 Ок
Я не понимаю о чём ваш комментарий. Я лишь повторил то, что есть в тикете.
Если вы считаете, что информация в тикете некорректная — то написать туда «вы ошибаетесь, всё работает так, как ожидается» будет эффективнее, чем сюда.
Я лишь говорю о том, что нааписано в репорте.
Если вы считаете, что информация в тикете некорректная — то написать туда «вы ошибаетесь, всё работает так, как ожидается» будет эффективнее, чем сюда.
Я лишь говорю о том, что нааписано в репорте.
Вы спросили «на какой запрос?», я дал вам исчерпывающий ответ, с экспериментом.
Они там и так знают, что эксперимент проведен с нарушениями. Я сам несколько раз выдел в коде php-разработчикв псевдо аттрибуты типа "_" => 9734985734957, для того чтобы Apache не кешировал запросы. Это трудности среды разработки, и к веб браузеру они не имеют никакого отношения.
Считайте, что это ответ на пост — «все работает так как ожидается»
А служба тех поддержки chrome боле меня осведомлена в попросах неожиданного поведения тех или иных сред разработки.
Они там и так знают, что эксперимент проведен с нарушениями. Я сам несколько раз выдел в коде php-разработчикв псевдо аттрибуты типа "_" => 9734985734957, для того чтобы Apache не кешировал запросы. Это трудности среды разработки, и к веб браузеру они не имеют никакого отношения.
Считайте, что это ответ на пост — «все работает так как ожидается»
А служба тех поддержки chrome боле меня осведомлена в попросах неожиданного поведения тех или иных сред разработки.
Мда. Для разработчиков это достаточно большая головная боль, когда были внесены изменения в js и css файлы а хром после многократных F5 отказывается изменения признавать.
Достаточно просто в урл добавлять номер билда :-)
В какой урл? Страницы открываемой дополнительный get параметр? Смысла тут нет, хром все закешировал. Скрипта? Это маразм, если ради каждой правки нужно будет править имя файла, а потом еще кучу мест его подключения. Речь, как правило, идет не о глобальный правках, а о правке пары строк в css. Вы что, заказчику вместо складных main.css, отдадите main-3.05.98.2004.css?
Нет, файлы и будут красивые, а вот урл будет перезаписываться вашим вебсервером.
/assets//css/main.css -> /assets/css/main.css
/assets//css/main.css -> /assets/css/main.css
Парсер съел часть:
/assets/<build>/css/main.css -> /assets/css/main.css
/assets/<build>/css/main.css -> /assets/css/main.css
Т. е. из-за хрома делать надстройку на сервере, чтобы такие адреса обрабатывались? А если это виртуальный хостинг клиента, где нужно делать мелкие правки?
Да и от необходимости править шаблоны, где прописаны пути это не избавляет.
Чем устраивать такое, проче отказаться от хрома при разработке и проверять сайт под FF, например, а в хроме только на финальной стадии.
Да и от необходимости править шаблоны, где прописаны пути это не избавляет.
Чем устраивать такое, проче отказаться от хрома при разработке и проверять сайт под FF, например, а в хроме только на финальной стадии.
Нет, не из-за хрома. А чтобы никогда ни с кем проблем не было.
Я решаю проблему так, как я описал.
Вы решаете — отказываясь от поддержки браузера.
У всех разные решения, я не настаиваю на том, чтобы вы стали делать как-то иначе.
Я решаю проблему так, как я описал.
Вы решаете — отказываясь от поддержки браузера.
У всех разные решения, я не настаиваю на том, чтобы вы стали делать как-то иначе.
Не от поддержки хрома, а от разработки приложения с использованием хрома (для мониторинга результата).
Угу, уже понял что не умею внимательно читать.
ps: а такая проблема реально существует? Просто я как-то не сталкивался с излишне агрессивным кэшем хрома (при условии, что вебсервер корректные заголовки отдаёт)
ps: а такая проблема реально существует? Просто я как-то не сталкивался с излишне агрессивным кэшем хрома (при условии, что вебсервер корректные заголовки отдаёт)
Да, существует проблема. Программист сидит, отлаживает верстку, которая порезана на шаблон CMS. Что-то не так, он просит верстальщика поправить. Тот по фтп правит css, js, буквально пару строк.
А вот программисту, чтобы увидеть изменения еще как нужно извернуться, чтобы увидеть изменения. html то по F5 сбрасывается кеш. А вот все подключаемые файлы — нет. Он даже не запрашивает картинки, css и js и чтобы их сбросить нужно либо сбросить кеш совсем, либо открыть каждый файл напрямую в браузере и там нажать F5.
Поэтому разработчику не удобно пользоваться хромом.
А вот программисту, чтобы увидеть изменения еще как нужно извернуться, чтобы увидеть изменения. html то по F5 сбрасывается кеш. А вот все подключаемые файлы — нет. Он даже не запрашивает картинки, css и js и чтобы их сбросить нужно либо сбросить кеш совсем, либо открыть каждый файл напрямую в браузере и там нажать F5.
Поэтому разработчику не удобно пользоваться хромом.
> А вот все подключаемые файлы — нет.
1. ctrl+f5
2. на продакшне нельзя ничего править
3. если хром кеширует файлы — значит этого попросил вэбсервер
В любом случае — это не проблема хрома.
1. ctrl+f5
2. на продакшне нельзя ничего править
3. если хром кеширует файлы — значит этого попросил вэбсервер
В любом случае — это не проблема хрома.
В настройках инспекторах Хрома есть пункт disable cache.
F12 — Options — Disable cache.
Второй вариант — два раза нажать Ctrl+R
Второй вариант — два раза нажать Ctrl+R
> А если это виртуальный хостинг клиента, где нужно делать мелкие правки?
Пардон за капитанство, но в продакшне вообще нельзя никаких правок вносить. А в случае с разработкой локально — можно билдить и перезаливать изменения.
> Да и от необходимости править шаблоны, где прописаны пути это не избавляет.
Не избавляет, но это автоматизируется
Пардон за капитанство, но в продакшне вообще нельзя никаких правок вносить. А в случае с разработкой локально — можно билдить и перезаливать изменения.
> Да и от необходимости править шаблоны, где прописаны пути это не избавляет.
Не избавляет, но это автоматизируется
Блин да вы прикалываетесь?
/css/main.css?build123
/css/main.css?build123
В чём принципиальная разница?
Избавляемся от совершенно ненужных rewrite-ов.
Это не «принципиальная» разница. Реврайт пишется 1 раз, и в отличие от текущего решения — урл становится «статическим»
Впечатление, что про ctrl+f5 никто не слышал…
> Это маразм, если ради каждой правки нужно будет править имя файла, а потом еще кучу мест его подключения.
Это всё должны делать билд-скрипты. Изменили что-то, сбилдили проект, отдали.
Это всё должны делать билд-скрипты. Изменили что-то, сбилдили проект, отдали.
При разработке сайта вообще могут не использоваться никакие билд скрипты, потому что они зачастую просто не нужны. Тем более при разработке на CMS. Верстальщик по фтп подправил строчку в css, и билд скрипт должен работать? Притом тут речь не о том, что сделали — отдали, а о том, что программист сидит, правит js, вносит изменения и смотрит результат, тестит, отлаживает, а у него они кешируются… Неужели на каждую правку новый билд создается? (а программист может до сотни раз скрипт пересохранять в ходе тестирования)
Добавляете в шаблон вместо прямой ссылки на css функцию, e.g.:
add_css(«css_file_name»);
Функция преобразует имя файла в /style/css/css_file_name.css?timestamp
timestamp — время последнего изменения файла.
add_css(«css_file_name»);
Функция преобразует имя файла в /style/css/css_file_name.css?timestamp
timestamp — время последнего изменения файла.
а в чем проблема собственно при подключении css указывать:
main.css?3.05.98.2004?
main.css?3.05.98.2004?
Это не хром виноват, это ваш веб сервер считает эти данные идентичными. Если ваше приложение отдает эти файлы как идентичные веб серверу, то следует разборки устраивать между веб сервером и сервером приложений. Хром сдесь вообще не при делах.
Я использую плагин Cache Killer. Когда отлаживаю верстку, нажимаю на кнопочку на панели инструментов, и кеш меня не беспокоит.
Думаю если сервер явно не указывает поведение cache-control броузер волен кешировать как ему удобнее.
Я во время разработки прописываю must-revalidate и хром отлично подгружает все изменения с сервера.
Я во время разработки прописываю must-revalidate и хром отлично подгружает все изменения с сервера.
мой хром поступает еще хуже: он запоминает изменения внесенные в css с помощью developer tools. обычный F5 не помогает. нужно только очистить кеш.
Кэширует запросы HTTP DELETE это еще ладно, но почему он не отключает автозаполнение форм через HTTPS, когда этого требует сервер? Это в может привести к более плачевным последствиям…
gayevoy.wordpress.com/why_autocomplete_doesnt_work_through_https_in_internet_explorer/
gayevoy.wordpress.com/why_autocomplete_doesnt_work_through_https_in_internet_explorer/
Sign up to leave a comment.
Chrome кэширует даже запросы HTTP DELETE