mvc - JQuery se quedó atrapado en la comprobación previa de CORS y la respuesta fantasma de IIS

net core api cors

Question

Estoy atascado. En serio ... - resuelto. sigue leyendo :)

Escenario : estoy tratando de hacer lo correcto aquí. Agregué la funcionalidad CORS a mi servicio REST (ASP.NET Web-API) confiando en Thinktecture Identitymodel CORS DelegatingHandler. Hasta aquí todo bien.

Para probar realmente si funciona, hice lo siguiente:

1. Configuré una página HTML simple y la publiqué en un host diferente al resto ( xttp: // otherhost / simplewebpage ). La página utiliza JQuery para realizar la solicitud de muestra. Código ver a continuación.
2. A continuación, configuré mi servicio de reposo para no usar iis express, sino la instancia completa de ejecución en mi máquina de desarrollo ( xttp: // developmenthost / restservice ).
3. Por último, pero no menos importante, en mi máquina de desarrollo abro el xttp: // otherhost / simplewebpage y disparo la solicitud de Ajax. La devolución de llamada de error se ejecuta diciéndome que hubo un "error de transporte" (IE9) o "" (cadena vacía) en Chrome. Me aseguré de que no haya problemas de conectividad relacionados con proxy o algo así.

Así que fui y miré las huellas de Fiddler y los registros de IIS. Fiddler dice que no hay una solicitud GET / rest / hello, sino más bien una solicitud OPTIONS / rest / hello, ¡lo cual es perfecto y esperado! Sin embargo, la respuesta a la solicitud OPTIONS es bastante intrigante.

El encabezado de respuesta completo se ve así:

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

Por supuesto, esto no está en ninguna parte ni cerca de la respuesta esperada. La parte divertida de esto es que la Solicitud ni siquiera llegó a Application_BeginRequest () en mi aplicación. Entonces, no hay forma de que mi aplicación sea responsable de ese resultado. Puedo ver la solicitud en mis registros de IIS e IIS agrega el encabezado Powered-by-ASP.NET ... por lo que definitivamente pasa a través del sitio IIS (correcto).

El código de JQuery que desencadena la solicitud de 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
        });
    }

La solicitud OPTIONS resultante tiene el siguiente aspecto:

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

... y ya has visto la respuesta a eso de arriba.

¿Alguna idea de quién responde exactamente mi solicitud de OPCIONES? ¿O es mi código JQuery defectuoso? El servicio REST funciona bien si uso, por ejemplo, Postman (aplicación Google Chrome) o si formo solicitudes en Fiddler (probablemente sea porque no hacen la negociación de CORS, no hay una solicitud de OPTIONS).

Actualización n. ° 1: hoy he leído que la deshabilitación de WebDAV es obligatoria porque interfiere con las solicitudes de OPTIONS. Mi vista Servicios de roles de IIS me dice que WebDAV Publishing no está instalado .

* Actualización n. ° 2: * ¿ Problema resuelto? Cavé más profundo. Hay un módulo registrado en IIS que es responsable de la respuesta "no deseada (?)" A la solicitud OPTIONS. Su nombre es "OPTIONSVerbHandler" (manejador: ProtocolSupportModule). Si desactivo ese módulo, la solicitud pasa a mi aplicación. ¡Se crea una respuesta más significativa y luego la solicitud GET real! ¡HURRA!

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

Una vez que sepa dónde está el problema, encontrará muchos recursos para decirle que se asegure de que su web.config se vea así: - /

<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>

Sin embargo, todavía no funciona en IE9 ("error: sin transporte"). En caso de que alguien haya pasado por el mismo camino que yo, es una cosa de IE9: https://stackoverflow.com/a/10232313/1407618

Answer 1

Comprueba este set-access-control-allow-origin-in-web-api . Esto puede ser útil.

Answer 2

Tu respuesta está aquí: https://gist.github.com/mathieucarbou/1114981

Básicamente, IE tiene algunas advertencias y errores bastante específicos para cors. Empecé a escribir uno una vez, pero luego encontré la solución de mathieucarbou y decidí que era mejor.

Esta puede ser una solución un poco más pesada de lo que usted quería, pero para compatibilidad con varios navegadores, he encontrado que es aceptable presionar IE con la "solución personalizada" tan duro como sea necesario.