Добавьте пользовательский заголовок в запрос Aurelia Fetch.

Я пытаюсь использовать клиент Aurelia Fetch для добавления пользовательского заголовка ко всем запросам GET и POST. Следующий код (в конструкторе app.js) работает для установки базового URL-адреса, но заголовки работают не так, как я хочу:

constructor(httpClient) {
  // set up httpClient
  httpClient.configure(config => {
    config
      .withBaseUrl(localsettings.api)
      .withDefaults({
        credentials: 'include',
        headers: {
          'my_appkey': 'f2eabc5e7de-a4cdc857e'
        }
      })
  });
  this.httpClient = httpClient;
}

Применение:

this.httpClient.fetch(suburl, {
    credentials: 'include'
  }).then(response => { ... });

С помощью инструментов разработки Chrome я вижу, что заголовок «my_appkey» существует, но он не создается как собственный заголовок, и его значение не видно:

Заголовки запроса:

OPTIONS /index.php/api/v1/keys HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:9000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Access-Control-Request-Headers: my_appkey
Accept: */*
Referer: http://localhost:9000/
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,es-419;q=0.6,es;q=0.4

Что я делаю не так? Почему мой пользовательский заголовок перемещается в Access-Control-Request-Headers?


javascript cors fetch-api aurelia
person LStarky    schedule 05.06.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Добавление заголовка my_appkey к запросу заставляет браузер сначала выполнить a Предварительный запрос OPTIONS CORS перед попыткой фактического запроса GET/POST, который вы хотите сделать.

OPTIONS /index.php/api/v1/keys HTTP/1.1
^^^^^^^

В рамках этой предварительной проверки OPTIONS браузер отправляет Access-Control-Request-Headersheader, значение которого включает имена заголовков, которые вы добавили в запрос из своего кода.

Заголовок запроса Access-Control-Request-Headers используется при выдаче предварительного запроса, чтобы сообщить серверу, какие заголовки HTTP будут использоваться при выполнении фактического запроса.

Итак, то, что вы видите, — это ожидаемое поведение.

И для того, чтобы браузер считал этот предварительный OPTIONS запрос успешным, сервер, на который направлен запрос, должен отправить ответ с Access-Control-Allow-Headers заголовок ответа, значение которого также включает "my_appkey". Если это не так, то браузер останавливается прямо здесь и никогда не продолжает отправлять фактический запрос GET/POST, который вы хотите сделать.

person sideshowbarker    schedule 05.06.2017
comment
Итак, анализируя это, возможно, добавление пользовательского заголовка — не лучший способ, поскольку это замедлит запрос (казалось бы, предварительный запрос добавит больше задержки). Каким будет более быстрый способ передать ключ приложения со всеми запросами? Просто включить его как часть тела? - person LStarky; 05.06.2017
comment
Да, если вы хотите избежать дополнительного запроса, я думаю, отправка ключа приложения как части тела запроса вместо заголовка будет самым простым способом сделать это. Тем не менее, если вы действительно хотите быстро, вы можете разместить свой код приложения на том же сервере/источнике, что и конечная точка API. - person sideshowbarker; 06.06.2017
comment
Если бы они были размещены на одном и том же поддомене (например, myapp.school.edu), то fetch отправил бы заголовок без необходимости выполнять предварительный запрос? - person LStarky; 06.06.2017
comment
Да, если бы они были размещены в одном и том же источнике (схема + хост + порт), то это не был бы запрос между источниками, поэтому браузер не налагал бы никаких ограничений между источниками и не использовал бы протокол CORS на все, что означает, что запрос будет выполнен успешно даже без заголовка ответа Access-Control-Allow-Origin. - person sideshowbarker; 06.06.2017