Здравствуйте.

Есть проблемка.
При кэшировании объекта с хедером Content-Type: application/json; charset=utf-8 (GET запрос вида domain.com/ajax/getProviders).
Он потом отдается HC из кэша без какого-либо Content-Type, и это портит работу некоторых других обработчиков, которые полагаются на Content-Type.
Только что обновил HC, думал, может это уже исправлено, но нет, в последней версией HC работает так же.

Надеюсь, что это можно поправить…

Спасибо.

PS: Несколько раз попробовал воспользоваться формой для отправки сообщения автору, но получал alert с текстом, что недостаточно прав для просмотра этой страницы. Так и не знаю, ушло мое сообщение, или нет, поэтому решил еще и тему создать.

> Аpplication/json - это вероятно данные, которые гоняют через сеть приложения.
В моем случае это на сайте при работе в таком виде приходят ответы на внутренние ajax запросы (которые работают без обновления страницы).

> Скорее всего их вообще не нужно кэшировать.
Очень даже нужно. Я работаю с сайтом, данные на которую загружаются таким вот методом. Данные эти не изменяются, то есть каждый раз из сервера грузятся те самые. С помощью HC я настроил кэширование этих данных, и могу не зависеть от отклика сервера. В результате вместо полминуты ожидания результатов всех запросов из сервера, всё работает моментально. Такое вот принудительное кэширование веб-приложения для более быстрой работы. Не для этого ли создавался HC?

Недавно что-то на сервере поменяли, и данные начали приходить с другим хедером. Теперь моя система не работает корректно, так как HC теперь отдает эти данные без параметра Content-Type вообще.

> Есть какие-то признаки в URL или содержимом, по которым их можно распознать?
В URL точно нет, а вот по содержимому можно определить, что это json, но нужно анализировать. Безопаснее было бы вместе с кэшем хранить оригинальные хедеры, которые были в ответе сервера (возможно только в тех случаях, когда это не можно определить по контенту файла в кэше).

В случае с JSON, подозреваю, что легче будет что-то записывать при сохранении, чем анализировать контент (очевидного признака вроде как нет).

>Если при записи еще пытаться определить контент, то будет лишняя нагрузка на компьютер.
Но ведь при записи тип известен из хедера и определять не нужно?

Получается оптимальная логика работы вроде такого:
Если пришел application/json (или какой-то другой трудно определимый по контенту тип данных), то вместе с кэшем сохраняем хедер; иначе — сохраняем только контент.
А при чтении из кэша наоборот: проверяем, если хедер сохранен вместе с кэшем — используем его, иначе — определяем по контенту, как сейчас.

Ну и, насколько я знаю, этих разных Content-Type есть больше количество, и могут же появляться новые. Неужели легче поддерживать в актуальном состоянии систему распознавания типа по контенту, чем просто сохранять то, что пришло в ответе от сервера?


Рас уж пошла речь о сохранении вместе с кэшем дополнительных данных, то есть смежная задача.
В HC можно включить кэширование POST запросов. И я пробовал это делать с той же описанной мною целью, когда на сайте используется POST для обмена данными с сервером. Ну и конечно напоролся на то, что URL у разных запросов получается одинаковый, и в результате для всех запросов при чтении из кэша возвращается одинаковый ответ, тот который был закэширован последним.
Если бы для таких запросов кроме url сохранялся хэш/чексумма (sha1, md5…) от данных, которые передаются, то можно было бы различать разные POST запросы ну и определять те, которые уже закэшированы.
Как вариант, этот хэш можно было бы приписывать к имени сохраняемого файла (если хэш-функция точно не использует специальные символов в генерируемых результатах).

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

Ну вот написал всё, что крутилось в голове. Возможно что-то пригодится…

Inversion, проще всего написать скрипт lua чтобы добавлялся Content-Type именно для твоих запросов.


вот собственно и всё, вроде бы...