JQuery застрял на предполетной проверке CORS и призрачном ответе IIS
Я застрял. Шутки в сторону... -решена. читать дальше :)
сценарий: ЯЯ пытаюсь сделать правильную вещь здесь. Я добавил функциональность CORS в свою службу REST (ASP.NET Web-API), опираясь на Thinktecture Identitymodel CORS DelegatingHandler. Все идет нормально.
Чтобы проверить, работает ли он, я сделал следующее:
Я установил простую HTML-страницу и опубликовал ее на другом хосте, чем остальные службы (xttp: // otherhost / simplewebpage). Страница использует JQuery, чтобы сделать пример запроса. Код смотри ниже.Затем я настроил службу отдыха так, чтобы она не использовала iis express, а использовала полностью запущенный экземпляр на моей машине для разработки (xttp: // developmenthost / restservice).И последнее, но не менее важное: на моем компьютере для разработки я открываю страницу xttp: // otherhost / simplewebpage и запускаю запрос Ajax. Ошибка обратного вызова выполняется, сообщая мне, что был "транспортная ошибка " (IE9) или "" (пустая строка) в Chrome. Я удостоверился тамНет проблем с прокси-связью или чем-то подобным.Поэтому я вышел и посмотрел на следы Fiddler и журналы IIS. Fiddler говорит, что нет запроса GET / rest / hello, а есть запрос OPTIONS / rest / hello - что вполне нормально и ожидаемо! Однако ответ на запрос OPTIONS довольно интригующий!
Весь заголовок ответа выглядит так:
HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
Server: Microsoft-IIS/7.5
Public: OPTIONS, TRACE, GET, HEAD, POST
Date: Fri, 15 Feb 2013 14:09:27 GMT
Content-Length: 0
Это, конечно, нигде даже близко к ожидаемому ответу.Самое интересное в том, что запрос недаже ударил Application_BeginRequest () в моем приложении. Так что'Нет, мое заявление не может нести ответственность за этот результат. Я вижу запрос в своих журналах IIS, и IIS добавляет заголовок Powered-by-ASP.NET .. так что он определенно проходит через (правильный) сайт IIS.
Код JQuery, который запускает запрос ajax:
function Run()
{
$.ajax({
type: 'GET',
url: url,
dataType: "json",
beforeSend: function(jqXhr) {
jqXhr.setRequestHeader("Authorization", "Basic " + getBasicHttpEncodedString(userName, password));
jqXhr.setRequestHeader("Api-Key", "123");
},
success: successCallback,
error: errorCallback,
timeout: 180*1000
});
}
Результирующий запрос OPTIONS выглядит так:
OPTIONS http://services.dev13/Rest/Hello HTTP/1.1
Host: developmenthost
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://otherhost/simplewebpage
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
Access-Control-Request-Headers: accept, origin, api-key, authorization
Accept: */*
DNT: 1
Referer: http://otherhost/simplewebpage
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
... и вы уже видели ответ на это выше.
Есть идеи, кто именно отвечает на мой запрос ОПЦИИ? Или мой код JQuery имеет недостатки? Служба REST прекрасно работает, если я использую, например, Postman (приложение Google Chrome) или подделываю запросы в Fiddler (That 'вероятно, потому что они непереговоры по CORS - естьНет запроса опций).
Обновление № 1: Ранее сегодня я где-то читал, что отключение WebDAV является обязательным, поскольку оно мешает запросам OPTIONS. Мое представление служб IIS Role Services сообщает мне, что публикация WebDAVНе установлено.
* Обновление № 2: * Задача решена?? Я копал глубже. Там's модуль, зарегистрированный в IIS, который отвечает за "нежелательная (?)» ответ на запрос ОПЦИИ. Его имя "OPTIONSVerbHandler» (обработчик: ProtocolSupportModule). Если я отключаю этот модуль, запрос передается в мое приложение. Там создается более значимый ответ, а затемс последующим запросом GET! УРА!
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: http://otherhost/simplewebpage
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: accept,origin,api-key,authorization
X-AspNet-Version: 4.0.30319
Date: Fri, 15 Feb 2013 15:09:25 GMT
Content-Length: 0
Как только вы узнаете, где проблема, конечно, вы найдете множество ресурсов, говорящих вам, чтобы убедиться, что ваш web.config выглядит так: - /
Это невсе еще работает в IE9 ("ошибка: нет транспорта "). В случае, если кто-то пошел по той же дороге, что и я -> Это'вещь IE9:https://stackoverflow.com/a/10232313/1407618