JQuery am stecken CORS-preflight-und IIS-ghost Antwort

Ich bin stecken. Ernst... - gelöst. Lesen Sie weiter 🙂

Szenario: ich versuche, das richtige zu tun hier. Ich fügte hinzu, CORS-Funktionalität, um meine REST-Dienst (ASP.NET Web-API) unter Berufung auf die Thinktecture Identitymodel CORS DelegatingHandler. So weit So gut.

Eigentlich testen ob es funktioniert habe ich Folgendes:

Ich eine einfache HTML-Seite und veröffentlicht es auf einem anderen host als der rest-Dienst (xttp://otherhost/simplewebpage). Die Seite verwendet JQuery, um die Probe anzufordern. Code siehe unten.
Nächstes richte ich mein rest-Dienst nicht für die Verwendung von iis express, sondern eher die voll ausgewachsenen Instanz läuft auf meinem Entwicklungsrechner (xttp://developmenthost/restservice).
Nicht zuletzt auf meiner Entwicklungs-Maschine, die ich öffnen die xttp://otherhost/simplewebpage und Feuer des Ajax-request. Der Fehler-callback sagt mir, es sei ein "transport error" (IE9) oder "" (leere Zeichenfolge) in Chrom. Ich stellte sicher, es ist kein proxy im Zusammenhang Verbindungsproblem oder ähnliches.

Also ging ich weiter und schaute auf die Fiddler ' Spuren-und IIS-Protokolle.
Fiddler sagt, es ist kein GET /rest/hello Wunsch, sondern eher eine OPTIONEN /rest/hello-request - und das ist völlig in Ordnung und erwartet! Jedoch die Antwort auf die OPTIONS-Anfrage ist ziemlich faszinierend!

Die gesamte response-header sieht wie folgt aus:

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

Dies ist natürlich nirgendwo auch nur annähernd die erwartete Antwort. Der Spaß Teil über diese ist, dass die Anfrage gar nicht getroffen Application_BeginRequest() in meiner Anwendung. Es gibt also keine Möglichkeit, meine Anwendung, die verantwortlich sein könnte für dieses Ergebnis. Ich kann sehen, dass der Wunsch in meinem IIS-Protokolle und-IIS fügt die Powered-by-ASP.NET header.. also es geht definitiv durch die (rechts) - IIS-Website.

Die JQuery-code, löst die ajax-Anfrage:

    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
        });
    }

Die daraus resultierenden OPTIONS-Anfrage sieht so aus:

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

... und Sie haben bereits gesehen, die Antwort auf die oben.

Ahnung, wer genau antwortet auf meine Anfrage OPTIONEN? Oder ist mein JQuery-code fehlerhaft?
Der REST-Dienst funktioniert nur gut, wenn ich zum Beispiel Briefträger (Google-Chrome-App) oder wenn ich forge Anforderungen in Fiddler (Das ist wahrscheinlich, weil Sie nicht tun CORS Verhandlung - es gibt keine OPTIONEN Anfrage).

Update #1: ich habe heute irgendwo gelesen, dass das deaktivieren von WebDAV ist obligatorisch, da stört es die OPTIONEN Anfragen. Mein IIS-Rollendienste Blick sagt mir, WebDAV-Veröffentlichung ist Nicht installiert.

* Update #2:* Problem gelöst?? Ich grub tiefer. Es gibt ein Modul registriert in IIS, die verantwortlich ist für die "unerwünschten(?)" Antwort auf die OPTIONS-Anfrage. Sein name ist "OPTIONSVerbHandler" (hf: ProtocolSupportModule). Wenn ich das deaktivieren, dass das Modul die Anfrage durchläuft, um meine Anwendung. Es gibt noch weitere aussagekräftige Antwort erstellt und dann gefolgt von der eigentlichen GET-Anforderung! YAY!

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

Sobald Sie wissen, wo das problem ist natürlich, finden Sie viele Quellen sagen, Sie stellen Sie sicher, dass Ihre web.config sieht so aus :-/

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="false">
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="OPTIONSVerbHandler" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
  </system.webServer>

Es nicht noch im IE9 obwohl die ("error: no transport"). Falls jemand ging den gleichen Weg wie ich -> es ist ein IE9 Sache: https://stackoverflow.com/a/10232313/1407618

versuchen Sie die crossDomain-Feld wahr..bei mir hat es geklappt
Sie sagte "problem gelöst?" Ist es eigentlich fest für Sie? Ich habe das gleiche Problem und habe versucht, alle diese Lösungen-und immer noch kein Glück.... Meine Frage stackoverflow.com/questions/22495240/...
Ich stehe vor ähnlichen Problem, bitte lassen Sie mich wissen, wenn Sie helfen konnte stackoverflow.com/questions/28213210/...
Ich habe nie bekommen Preflight-Anforderungen an die Arbeit mit IIS, endete mit Bildern statt brrrr
Ich war wendet man diese behebt, aber es hat nicht geholfen. Jede HTTP-OPTIONS-Anforderung konnte nicht durch bekommen, es wurde noch keine log-in IIS-Protokolldateien für die OPTIONS-Anfrage. Nach 2 Stunden Frust, und wenn ich war völlig hoffnungslos, ich beschloss, starten Sie den wcf-Dienst-Webanwendung in IIS, und es plötzlich funktionierte !! Soweit ich weiß IIS neu gestartet, den Anwendungspool, wenn die config-Datei geändert, aber dieses mal ist es nicht neu starten. Es spielt keine Rolle, ich wollte nur, um es arbeiten und es ist geschafft. +1 für das. Hoffe, dies hilft jemand ..
Ich war mit Microsoft.Owin.Cors und Microsoft.AspNet.WebApi.Cors und es wurde auf IIS Express aber nicht auf IIS. IIS antwortet immer dieses 'Ghost Anfrage', die Sie erwähnt, und gelöst durch entfernen der OPTIONSVerbHandler. Gut fangen, +1

InformationsquelleAutor lapsus | 2013-02-15

Erstellen PreflightRequestsHandler Klasse, wo Sie zulassen request-Header(1) und aktivieren cors, bevor Sie Ihre Klasse(2).

1. public class PreflightRequestsHandler : DelegatingHandler
    {
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            if (request.Headers.Contains("Origin") && request.Method.Method.Equals("OPTIONS"))
            {
                var response = new HttpResponseMessage { StatusCode = HttpStatusCode.OK };
                //Define and add values to variables: origins, headers, methods (can be global)               
                response.Headers.Add("Access-Control-Allow-Origin", "*");
                response.Headers.Add("Access-Control-Allow-Headers", "content-type");
                response.Headers.Add("Access-Control-Allow-Methods", "*");
                var tsc = new TaskCompletionSource<HttpResponseMessage>();
                tsc.SetResult(response);
                return tsc.Task;
            }
            return base.SendAsync(request, cancellationToken);
        }

    }

2. [EnableCors(origins: "*", headers: "*", methods: "*", exposedHeaders: "X-Custom-Header")]

InformationsquelleAutor Kalyani Rathore

1

Ihre Antwort hier:
https://gist.github.com/mathieucarbou/1114981

Grundsätzlich, DH hat einige ziemlich spezifische Einschränkungen und Fallstricke für cors. Ich begann mich sofort, aber dann fand ich mathieucarbou Lösung und beschloss seine besser war.

Dies ist möglicherweise ein wenig schwerer, eine Lösung, als du wolltest, aber für cross-browser-Unterstützung, die ich habe festgestellt, dass es akzeptabel sein hit DH mit der "custom-Lösung" so hart wie es dauert.
- Klar, das ist nur eine Antwort auf die Frage IE9-Unterstützung, das wurde nur erwähnt, ganz am Ende der Frage und nur nach den wichtigsten Teil der Frage gelöst worden.
InformationsquelleAutor Luke
0

Überprüfen Sie diese set-access-control-allow-origin-im-web-api.Dies kann Ihnen dabei helfen.
- Das problem ist, dass der IIS ist ein abfangen des OPTIONEN-Methode Transaktionen. Die app sieht nie diesen Verkehr, so dass keine änderungen an der app gehen, hier zu helfen.
InformationsquelleAutor Arun Raj

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.