Предварительный запрос запроса CORS, заканчивающийся кодом пользователя

У меня есть набор веб-служб WCF, работающих только на внутреннем интерфейсе, которые вызываются рядом других веб-сайтов (также только внутренних). Имена доменов совпадают, это просто другой номер порта.

Я делаю запросы AJAX POST к этим веб-службам, и, поскольку они технически не одного происхождения (другой порт), я использую CORS.

В IE все в порядке (поскольку я считаю, что IE не рассматривает порты как разные источники), однако и Opera, и Firefox отправляют предварительный запрос OPTIONS.

Я настроил веб-службы для приема этих запросов через файл web.config:

<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="POST, GET, OPTIONS" />
<add name="Access-Control-Allow-Headers" value="*" />

Я также настроил интерфейс своих сервисов на прием любого HTTP-глагола:

[OperationContract(Name = "H2dbDataExport")]
[WebInvoke(Method = "*", BodyStyle = WebMessageBodyStyle.Wrapped, RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)]
string H2dbDataExport(string action, string username, exportDetails data);

Однако это приводит к вызову базовой службы, и поскольку она не находит никаких деталей, которые можно было бы ожидать в ответах на запрос POST со стандартным ответом «Вы отправили что-то не так».

Если я изменю службу, чтобы принимать только запрос POST - это действительно единственный ответ, на который он ответит чем-либо таким же через:

[WebInvoke(Method = "POST", etc.......

Затем ВАРИАНТЫ предварительной проверки получают ответ «405 - метод не разрешен».

Что я делаю не так? Должен ли я настраивать свои службы для ответа на запрос OPTIONS, и если да, то каким будет правильный ответ?

Я предполагаю, что я мог бы просто выбрать тип запроса в службе и ответить 200 - ОК, если глагол был ВАРИАНТЫ, то повторно отправить фактический POST - но если я сделал это вручную, наверняка браузер просто отправит ВАРИАНТЫ снова как это новый запрос.

РЕДАКТИРОВАТЬ:

Я только что нашел этот пост, касающийся удаления обработчика WEbDAV: CORS 405 (метод не разрешен )

Но это не помогло.

Также был пост о перемещении обработчика OPTIONSHttpVerb в начало списка и предоставлении ему разрешений «Чтение», но это также не помогло.

РЕДАКТИРОВАТЬ 2: На самом деле перемещение OPTIONSHttpVerb действительно помогло, оно больше не вызывает веб-службу, но IIS отвечает 200 - OK. Однако этот ответ по-прежнему попадает в клиентский код в браузере, поэтому бесполезен.

ВАРИАНТЫ ответа

HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
Server: Microsoft-IIS/7.5
Public: OPTIONS, TRACE, GET, HEAD, POST
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: *
Access-Control-Max-Age: 1728000
Date: Fri, 05 Jun 2015 10:34:29 GMT
Content-Length: 0

http cors options wcf httpverbs
person Morvael    schedule 05.06.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Похоже, это была моя вина. Я использовал подстановочный знак для:

<add name="Access-Control-Allow-Headers" value="*" />

Что, видимо, не разрешено. Если в запросе указаны заголовки Access-Control-Request-Headers, сервер должен ответить тем же списком.

https://stackoverflow.com/a/13147554/1286358

http://www.html5rocks.com/en/tutorials/cors/

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

В предварительном запросе была эта строка:

Access-Control-Request-Headers: accept, content-type

Поэтому я изменил web.config, чтобы он соответствовал:

<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="POST, GET, OPTIONS" />
<add name="Access-Control-Allow-Headers" value="accept, content-type" />

И теперь это работает.

Это также позволило мне снова изменить службу (правильно) только на прием POST-запросов.

[WebInvoke(Method = "POST", etc.......

Надеюсь, это поможет кому-то еще.

person Morvael    schedule 05.06.2015

arrow_upward
2
arrow_downward

Недостаточно кармы, чтобы прокомментировать, поэтому я просто помещу это здесь для всех, кто, как и я, пришел к этому вопросу и ответил, потому что IE11 не будет отправлять запрос POST после успешного запроса OPTIONS (200 OK)

Причина, по которой это не сработало для меня, заключается в том, что заголовки Response были помещены в регистр, а заголовки Request - нет, то есть:

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

Access-Control-Request-Headers: content-type, accept

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

Access-Control-Allow-Headers: Content-Type, Accept

Что является нарушением стандарта HTTP/1.1 BTW, см. https://stackoverflow.com/a/5259004/1602497.

person right    schedule 24.08.2016