tenga - Error de solicitud incorrecta HTTP al solicitar un contrato de servicio WCF
hubo un error al descargar los metadatos desde esta direccion (5)
Creo que descubrí cuál es el problema.
Si navego a la URL:
con la aplicación WcfTestClient puedo recuperar con éxito los metadatos del servicio.
Entonces, el error realmente solo ocurre cuando solicito la URL a través de un navegador web.
El error HTTP Bad Request proviene del hecho de que el navegador emite una solicitud HTTP GET donde el contenido del mensaje se encuentra en los encabezados HTTP y el cuerpo está vacío.
¡Esto es exactamente de lo que se queja el WCF mexHttpBinding !
Para llegar al contrato de servicio a través de un navegador web, deberá habilitarlo explícitamente en el comportamiento del servicio:
<serviceBehaviors>
<behavior name="MetadataEnabled">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
La URL para solicitar se convierte en:
Entonces, resultó ser demasiado rápido para publicar esta pregunta. Sin embargo, lo mantendré de todos modos solo para el registro.
Tengo un servicio WCF con la siguiente configuración:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="MetadataEnabled">
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MetadataEnabled" name="MyNamespace.MyService">
<endpoint name="BasicHttp"
address=""
binding="basicHttpBinding"
contract="MyNamespace.IMyServiceContract" />
<endpoint name="MetadataHttp"
address="contract"
binding="mexHttpBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/myservice" />
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
Al hospedar el servicio en el proceso WcfSvcHost.exe , si navego a la URL:
donde los metadatos del servicio están disponibles obtengo un error HTTP 400 Bad Request .
Al inspeccionar los registros de WCF descubrí que se está lanzando una excepción System.Xml.XmlException con el mensaje: " El cuerpo del mensaje no se puede leer porque está vacío " .
Aquí hay un extracto del archivo de registro:
<Exception>
<ExceptionType>
System.ServiceModel.ProtocolException, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
</ExceptionType>
<Message>There is a problem with the XML that was received from the network. See inner exception for more details.</Message>
<StackTrace>
at System.ServiceModel.Channels.HttpRequestContext.CreateMessage()
at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, ItemDequeuedCallback callback)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore(IAsyncResult result)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext(IAsyncResult result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.ListenerAsyncResult.WaitCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
</StackTrace>
<InnerException>
<ExceptionType>System.Xml.XmlException, System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
<Message>The body of the message cannot be read because it is empty.</Message>
<StackTrace>
at System.ServiceModel.Channels.HttpRequestContext.CreateMessage()
at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, ItemDequeuedCallback callback)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore(IAsyncResult result)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext(IAsyncResult result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.ListenerAsyncResult.WaitCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
</StackTrace>
</InnerException>
</Exception>
Si, en cambio, navego a la URL:
todo funciona bien y obtengo el contrato WSDL. En este punto, también puedo eliminar completamente el punto final de metadatos "MetadataHttp" , y no haría ninguna diferencia.
Estoy usando .NET 3.5 SP1. ¿Alguien tiene una idea de lo que podría estar mal aquí?
Pude solucionar el problema de "400 solicitudes incorrectas" al cambiar mi servicio WCF de Visual Studio Development Server a utilizar el servidor web local IIS (haga clic con el botón derecho en el proyecto -> propiedades -> pestaña web -> radio debajo de "Servidores"). Espero que esto ayude a alguien porque me tomó dos días resolver esto.
En general, este es un problema con el tamaño del sobre SOAP. Compruebe su configuración de enlace para cambiar MaxBufferPoolSize, MaxReceivedMessageSize para permitir grandes contenidos. Recuerde, debe cambiar tanto en el lado del cliente como del servidor.
Otro problema es el MessageEnconding (otro parámetro de enlace), asegúrese de que el lado del cliente y del servidor estén usando la misma codificación.
Finalmente, verifique los parámetros de las propiedades de las cuotas de Reader.
Tuve problemas HTTP 400 al consumir una URL HTTPS mex desde SvcUtil, aunque httpsGetEnabled se estableció en true . El mensaje de error estaba muy lejos de lo que realmente era el problema, así que estoy publicando aquí en caso de que alguien se tropiece con el mismo problema.
Tenía un certificado de CA autofirmado (TestRootCA) que era el emisor del certificado del servidor (localhost). En el cliente importé el archivo TestRootCA CER pero no importé la CRL (lista de revocación de certificados). Parece que cuando usa una CA autofirmada también debe importar la CRL, de lo contrario, la autenticación del servidor falla de manera extraña, ninguna de las cuales lo señala al problema real. Lo que es peor es que el error ocurre durante el protocolo de enlace SSL, antes de que la solicitud llegue a su servicio, por lo que no verá errores en los registros de seguimiento de WCF.
Si no está seguro de por qué su código WCF arroja un error, le recomiendo el MS Service Trace Viewer. Es muy útil para identificar problemas de comunicación y transporte como este. Eche un vistazo a este artículo de C # Corner para más detalles.