Заголовок Access-Control-Allow-Origin не работает. Что я делаю неправильно?

Я пытаюсь предоставить ответ на метод HTTP OPTIONS с заголовком Access-Control-Allow-Origin, копирующим содержимое заголовка Origin в запросе.

Это, по-видимому, не работает, по причинам, которые я не могу понять.

tl;dr: ответ от OPTIONS гласит:

Access-Control-Allow-Origin: http://10.0.0.105:9294

последующий GET имеет:

Origin:http://10.0.0.105:9294

Хром говорит:

Origin http://10.0.0.105:9294 is not allowed by Access-Control-Allow-Origin

Что не так?

Подробнее...

Глядя в окно инструментов разработчика Chrome, заголовки запросов:

OPTIONS /user/kris HTTP/1.1
Host: 10.0.0.104:8080
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://10.0.0.105:9294
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1
Access-Control-Request-Headers: origin, x-requested-with, content-type, accept
Accept: */*
Referer: http://10.0.0.105:9294/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Заголовки ответа:

HTTP/1.0 200 OK
Date: Mon, 13 Aug 2012 11:23:45 GMT
Server: WSGIServer/0.1 Python/2.7.3
Content-Length: 0
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD, OPTIONS
Access-Control-Max-Age: 10
Access-Control-Allow-Origin: http://10.0.0.105:9294
Access-Control-Allow-Headers: X-Requested-With, Authorization, X-Huzu-User, Content-Type, Accept
Content-Type: text/html; charset=UTF-8

После того, как jQuery отправляет свой запрос OPTIONS и получает приведенный выше ответ, происходят две странные вещи. Ответ OPTIONS (200) отображается в консоли разработчика как ошибка:

OPTIONS http://10.0.0.104:8080/user/kris 200 (OK)

После чего запрос GET отклоняется. Ошибка в консоли:

XMLHttpRequest cannot load http://10.0.0.104:8080/user/kris. Origin http://10.0.0.105:9294 is not allowed by Access-Control-Allow-Origin.

Я не понимаю, почему бы и нет. Что я делаю неправильно?


person scav    schedule 13.08.2012    source источник
comment
У меня нет минимального ошибочного примера кода jQuery, который можно было бы опубликовать здесь. Предположим, что в коде javascript нет ничего странного, то есть это всего лишь один jQuery get(), в результате чего появляется запрос OPTIONS, опубликованный выше. Мой вопрос: что не так с ответом?   -  person scav    schedule 13.08.2012
comment
Это только я или есть разница между URL-адресом хоста (10.0.0.104:8080) и URL-адресом реферера (10.0.0.105:9294/)?   -  person rene    schedule 13.08.2012
comment
@рене да. Мой сервер представляет собой приложение python wsgi, работающее на моем локальном компьютере (10.0.0.104:8080), и межсайтовое тестирование происходит со страницы, которую я загружаю с 10.0.0.105:9294. Я не знаю, какое влияние реферер оказывает на контроль доступа. Как вы думаете, это актуально? Если да, то что мне с этим делать?   -  person scav    schedule 13.08.2012
comment
Если вы запустите браузер в версии 10.0.0.4, вы не сможете загрузиться из версии 10.0.0.105. Этот заголовок также должен иметь 10.0.0.4:8080 в качестве разрешенного адреса: Access-Control-Allow-Origin: 10.0.0.105:9294   -  person rene    schedule 13.08.2012
comment
@rene: 10.0.0.104:8080 не является источником запросов. Это сам сервер. JavaScript загружается из 10.0.0.105:9294, так что это источник. Или я совсем не понимаю? Попробую с браузером на 10.0.0.105 и посмотрим, поможет ли это. Кстати, я думаю, что некоторые браузеры (FF) принимают только один хост в этом заголовке.   -  person scav    schedule 13.08.2012
comment
это не помогает запускать браузер на том же хосте, что и приложение javascript.   -  person scav    schedule 13.08.2012
comment
Возможно, это то же самое, что и stackoverflow.com/questions/11580200/   -  person scav    schedule 13.08.2012


Ответы (1)


Хорошо, я думаю, что понял. Кажется, что правильная обработка запроса OPTIONS перед запуском необходима, но НЕ ДОСТАТОЧНА для работы межсайтовых запросов ресурсов.

После того, как запрос OPTIONS возвращается с удовлетворительными заголовками, все ответы на любые последующие запросы к тому же URL-адресу также должны иметь необходимый заголовок «Access-Control-Allow-Origin», иначе браузер проглотит их. , и они даже не будут отображаться в окне отладчика.

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

person scav    schedule 14.08.2012
comment
Поскольку вы закончили с вашим запросом, можете ли вы помочь мне в этом похожем вопросе? stackoverflow.com/questions/11953132/ - person Prashant Singh; 14.08.2012
comment
@scav +1 Не могу тебя отблагодарить. Вы сэкономили мне часы отладки! - person alf; 24.02.2013
comment
Также происходит сбой, если Access-Control-Allow-Origin:*, установленный вами в фактическом ответе, не совсем соответствует тому, который использовался в предварительном запросе OPTIONS. Я случайно добавлял его дважды в asp dot net, один раз в конфигурации IIS и один раз в коде загрузки страницы, что означало, что Access-Control-Allow-Origin:* произошло один раз в предварительных ОПЦИЯХ, но дважды в фактическом ответе, поэтому Chrome отменил это. - person Martin Belcher - AtWrk; 21.06.2013
comment
просто во-вторых это ... Chrome (v33 в настоящее время), кажется, требует, чтобы ответ 304 также имел заголовки Access-Control-Allow-Origin: * и т. д., а не только в ответе начальных параметров. Firefox (v27), кажется, не возражает - person Anentropic; 26.03.2014
comment
Работает удовольствие - у меня был один файл, запрашивающий другой, установка обоих заголовков решила проблему :) - person Rog; 17.06.2019
comment
В моем случае причиной ошибки была переадресация 301 в Lumen (например, с /api-endpoint/ на /api-endpoint). - person Robert Dundon; 17.06.2020
comment
Что такое предполетные ВАРИАНТЫ? Работал с вебом 15 лет и никогда о нем не слышал. Вы делаете запрос и получаете ответ.... Это очень сбивает с толку - person OZZIE; 16.11.2020