Как применять кеш-память CORS для всего домена

Я создаю приложение REST, которое использует CORS. Каждый вызов REST отличается, и я нахожу, что есть значительные накладные расходы при получении вызова OPF. Есть ли способ кэшировать и применять результат предполетных OPTIONS, чтобы любые последующие вызовы в тот же домен использовали кешированный ответ?

Предпросмотр может применяться только к запросу, а не ко всему домену. Я включил тот же вопрос в список рассылки, и были проблемы с безопасностью. Вот весь stream: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0228.html

Есть несколько вещей, которые следует учитывать, если вы хотите ограничить количество предполетных запросов. Прежде всего обратите внимание, что браузеры, основанные на WebKit / Blink, устанавливают максимальный кеш preflight в 10 минут:

https://github.com/WebKit/webkit/blob/master/Source/WebCore/loader/CrossOriginPreflightResultCache.cpp https://chromium.googlesource.com/chromium/blink/+/master/Source/core/loader/CrossOriginPreflightResultCache .cpp

(Я не уверен, что это верно для других браузеров). Поэтому, когда вы всегда должны устанавливать заголовок Access-Control-Max-Age, максимальное значение составляет 10 минут.

Далее следует отметить, что невозможно избежать предполетных запросов PUT / DELETE. Таким образом, обновления / удаления для вашего API потребуют по крайней мере одного предполета каждые 10 минут.

В GET / POST избегайте настраиваемых заголовков, если это вообще возможно, поскольку они все еще запускают предвыборные кампании. Если ваш API возвращает JSON, обратите внимание, что Content-Type ‘application / json’ также запускает предполетную проверку.

Если вы готовы сгибать, как «RESTful» ваш API, есть еще несколько вещей, которые вы можете попробовать. Один из них – использовать Content-Type, который не нуждается в предполетне, например «text / plain». Пользовательские заголовки всегда вызывают предвестники, поэтому, если у вас есть пользовательские заголовки, вы можете переместить их в параметры запроса. В крайнем случае вы можете использовать протокол, такой как JSON-RPC, где все запросы отправляются на одну конечную точку.

Честно говоря, из-за пределов кэша preflight браузера, равного 10 минутам, и URL-адресов ресурсов REST, кеш предполетного контроля довольно бесполезен. Это очень мало, что вы можете сделать, чтобы ограничить префлоуты в течение долгого приложения. Я надеюсь, что авторы спецификации CORS попытаются решить эту проблему в будущем.

Попробуйте использовать xDomain

Для меня было довольно просто настроить использование углового или jQuery. На сервере приложений добавьте proxy.html, как указано в справке по ссылке ниже. Добавьте несколько тегов, относящихся к файлам js на вашем «клиенте» и альте, не более предполет. Это обертывает iframe, чтобы избежать необходимости проверки cors.

https://github.com/jpillora/xdomain

Одним из способов является то, что вы можете указать все ваши вызовы API в том же домене, что и ваш интерфейс. Установите nginx на интерфейсный сервер, чтобы перенаправлять только вызовы API на сервер API. Это приведет к удалению всех предполетных вызовов.

  • Отдых с весны и корс
  • CORS. Какова мотивация внедрения предполетных запросов?
  • Как я могу исправить проблему веб-сайта «Отсутствующий перекрестный источник ресурсов (CORS)»?
  • jQuery CORS Варианты типа контента
  • Проблема CORS - заголовок «Access-Control-Allow-Origin» отсутствует на запрошенном ресурсе
  • Ajax с использованием https на странице http
  • Включить CORS в Web API 2
  • CORS: нельзя использовать подстановочный знак в Access-Control-Allow-Origin, когда флаг учетных данных верен
  • CORS включен, но ответ для предполета имеет недопустимый код статуса HTTP 404, когда POSTING JSON
  • Символ Cors Access-Control-Allow-Headers игнорируется?
  • Фильтр Tomcat CORS
  • Давайте будем гением компьютера.