Почему нестандартные заголовки включены в Access-Control-Request-Headers?

Я пытаюсь отправить запрос о перекрестном происхождении. Что касается Access-Control-Request-Headers, я получаю различное поведение в FireFox, Chrome и Safari.

Chrome :- Access-Control-Request-Headers:  origin, content-type, accept
Safari :- Access-Control-Request-Headers:  origin, content-type, accept
Firefox:- Access-Control-Request-Headers:  content-type

Мои вопросы: -

  1. Как браузеры решают, какие заголовки будут частью Access-Control-Request-Headers?
  2. Насколько я знаю, в Access-Control-Request-Headers должны быть только пользовательские заголовки, но все три (accept, origin и content-type) не являются пользовательскими заголовками. Тогда почему они являются частью заголовков Access-Control-Request-Headers?
  3. Почему поведение зависит от браузера?

google-chrome cors ajax http-headers firefox
person maneet    schedule 26.06.2013    source источник

Ответы (1)


arrow_upward
9
arrow_downward

Здесь происходит много разных вещей, поэтому я отвечу на них по одному.

Chrome и Safari основаны на WebKit, поэтому вы видите одинаковое поведение в этих браузерах (Chrome скоро переходит на Blink, но это еще не в руках пользователей).

В последней спецификации CORS указано, что Accept — это простой заголовок запроса. Origin не входит в список простых заголовков запросов, но было бы глупо не поддерживать его, поскольку он является основой CORS. Так что технически Firefox поступает правильно.

Однако обратите внимание, что хотя Chrome/Safari включают заголовки Accept и Origin, они не проверяют, включены ли эти заголовки в заголовок ответа Access-Control-Allow-Headers. Вы можете убедиться в этом, перейдя по следующей ссылке:

http://client.cors-api.appspot.com/client#?client_method=PUT&client_credentials=false&client_headers=Accept%3A%20%2A%2F%2A&server_enable=true&server_status=200&server_credentials=false&server_methods=PUT&server_tabs=local

Обратите внимание, что предварительный запрос имеет заголовок Access-Control-Request-Headers: accept, origin, но в ответе нет Access-Control-Allow-Headers. И фактический запрос CORS по-прежнему выполняется успешно.

Заголовок Content-Type считается простым заголовком запроса, только если его значение является одним из следующих: application/x-www-form-urlencoded, multipart/form-data или text/plain. Все остальные значения вызовут предварительную проверку. Это, вероятно, то, что вы видите здесь.

Я понятия не имею, почему браузеры ведут себя таким образом. Это может быть что-то, что стоит спросить на досках объявлений WebKit или Firefox. Вот код, в котором WebKit устанавливает заголовок Access-Control-Request-Headers:

https://trac.webkit.org/browser/trunk/Source/WebCore/loader/CrossOriginAccessControl.cpp?order=name#L117

Кажется, что он перечисляет все заголовки, не удаляя простые заголовки. Я предполагаю, что на стороне ответа есть код, который ожидает только непростых заголовков в ответе Access-Control-Allow-Headers.

person monsur    schedule 27.06.2013
comment
привет, еще одна вещь, используя chrome, я устанавливаю значение заголовка dauth. но в скрипаче он показывает мне Access-Control-Request-Headers: content-type, dauth, x-akamai-acs-action. Принимая во внимание, что если я --disbale-web-security для chrome, он показывает мне значение DAUTH: XXXXXXX .... любая идея, почему он не добавляет значение заголовка в предыдущем случае - person Taran; 12.10.2015