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

Ответы на вопрос(2)

Ваш ответ на вопрос