IIS 7.5, servicio web y error HTTP 405

Tengo un servicio web que hospedo en mi máquina. Uso Windows 7 e IIS 7.5.

Problema : cuando el cliente intenta consumir el servicio web, obtiene un error HTTP 405.

En el archivo de registro de IIS, puedo ver que esto se rechaza porque el verbo POST no está permitido.

Pregunta : ¿Cómo puedo permitir el verbo POST para esas solicitudes?
¿Debo agregar la asignación del archivo WSDL? Y si lo hago, ¿cómo debo configurar este mapeo? Lo he comprobado, y en las asignaciones existentes no tengo nada para la extensión WSDL.

¿Hay algo más que configurar en IIS para permitir esas solicitudes?

El servicio web está construido usando WCF .

Después de horas luchando, esta es la solución final que me ayudó (probado desde el violín):

  1. En IIS 7.5 -> YourWebsite -> Asignaciones de manejador
  2. Elija la opción “Agregar asignación de módulo” en el lado derecho del panel
  3. En el campo “Ruta de solicitud” ingrese * .wsdl
  4. En el campo “Módulo”, ingrese “ProtocolSupportModule”
  5. Haga clic en “Solicitar restricciones” y vaya a la pestaña Verbos
  6. Ingrese el verbo POST
  7. Guardar cambios

Fin voila, violinista ya no responde con 405 pero con feliz 200.

La respuesta enumerada no funcionó para mí, pero pude solucionar el problema ejecutando

“% WINDIR% \ Microsoft.Net \ Framework \ v3.0 \ Windows Communication Foundation \ ServiceModelReg.exe” -r

Esto volvió a registrar la asignación del controlador para * .svc

Ir al Administrador de IIS -> Seleccionar sitio web -> Asignación de controlador -> Seleccionar el controlador -> hacer clic con el botón derecho y seleccionar editar -> Solicitar restricciones -> pestaña de verbos

Cambia el valor allí.

Dependiendo de su extensión, podría ser un controlador diferente.

Para las personas que se topan con esta página pero que están realizando solicitudes a una aplicación web con páginas aspx, en lugar de servicios, hay algo importante que destacar.

Si realiza una solicitud http post de fiddler a http://localhost/MyApplication , arrojará el estado 405. Pero si especifica http://localhost/MyApplication/Default.aspx , responderá correctamente (con estado 200)

Espero que esto ayude. He estado buscando en el lugar equivocado durante una hora, depurando manejadores, módulos, configuraciones de webdav, verbos http, etc.

Resulta que no tenía habilitada la Activación HTTP de WCF. Solución aquí: WCF en IIS8; * El mapeo del controlador .svc no funciona

Ahh: finalmente encontré una solución para mis CORS en el infierno de IIS. Este fue uno de los problemas que surgieron durante la búsqueda de mi solución.

La respuesta correcta es la de aliostad: el problema proviene del hecho de que para algunas soluciones para implementar el verbo ‘OPTIONS’, se recomendaba eliminar el mapeo de ese verbo al ProtocolSupportModule. O tal vez alguien acaba de limpiar las asignaciones innecesarias, etc. Esto no dejó ningún controlador para OPCIONES.

No soy un experto en exactamente lo que ocurre detrás de las escenas, pero parece que IIS se asegura de que haya un controlador potencial para la solicitud mucho antes de que se active el evento Application_BeginRequest, esto a pesar de sus diagtwigs de secuencia:

https://msdn.microsoft.com/en-us/library/bb470252.aspx

Entonces se devuelve un estado 405 sin ejecutar su módulo. Lo que se estaba enviando al servidor es, por ejemplo:

 OPTIONS http://www.example.com/path/mypage.aspx 

Así que IIS está buscando un controlador para * .aspx que acepte el verbo OPTIONS. Si mira su archivo applicationHost.config predeterminado, verá, por ejemplo:

      

Acabo de hacer lo siguiente en mi web.config para hacer que IIS deje de devolver el estado 200 noops:

   

Entonces, probándolo al principio, y concluyendo que esto es lo que necesitaba, agregué lo siguiente a mi web.config:

          

Tenga en cuenta que los reemplazos coinciden con lo que está en applicationHost.config, excepto con el verbo adicional OPTIONS añadido a cada línea.

Para aquellos de ustedes que usan enrutamiento (MVC o webapi por ejemplo):

        

Por último, no soy un experto en IIS, quizás haya una manera diferente y más eficiente de manejar el verbo OPTIONS para CORS (más específicamente, permitir que su controlador CORS funcione sin la solución parcial de ‘encabezado personalizado’, estoy abierto a aquellos soluciones.