c# - the - WCF Service Client: El tipo de contenido text/html; charset=utf-8 del mensaje de respuesta no coincide con el tipo de contenido de la vinculación
response not of type text/xml: text/html; charset=utf-8 (15)
Al igual que con muchos, en mi situación yo también recibía esto debido a un error. Y, lamentablemente, podría leer el CSS de la página de error html.
La fuente de mi problema también era una regla de reescritura en el servidor. Estaba reescribiendo http a https.
Tengo un servicio WCF ejecutándose en mi servidor IIS local. Lo agregué como una referencia de servicio a un proyecto de sitio web C # y agrega bien y genera las clases proxy automáticamente.
Sin embargo, cuando intento llamar a cualquiera de los contratos de servicio, aparece el siguiente error:
Descripción: se produjo una excepción no controlada durante la ejecución de la solicitud web actual. Revise el seguimiento de la pila para obtener más información sobre el error y dónde se originó en el código.
Detalles de la excepción: System.ServiceModel.ProtocolException: el tipo de contenido text / html; charset = utf-8 del mensaje de respuesta no coincide con el tipo de contenido del enlace (application / soap + xml; charset = utf-8). Si utiliza un codificador personalizado, asegúrese de que el método IsContentTypeSupported se implemente correctamente. Los primeros 1024 bytes de la respuesta fueron: ''función bredir (d, u, r, v, c) {var w, h, wd, hd, bi; var b = falso; var p = falso; var s = [[ 300,250, falso], [250,250, falso], [240,400, falso], [336,280, falso], [180,150, falso], [468,60, falso], [234,60, falso], [88,31, falso], [120,90, falso], [120,60, falso], [120,240, falso], [125,125, falso], [728,90, falso], [160,600, falso], [120,600, falso] , [300,600, falso], [300,125, falso], [530,300, falso], [190,200, falso], [470,250, falso], [720,300, verdadero], [500,350, verdadero], [550,480, verdadero]]; if (typeof (window.innerHeight) == ''number'') {h = window.innerHeight; w = window.innerWidth;} else if (typeof (document.body.offsetHeight) == ''number'') {h = document. body.offsetHeight; w = document.body.offsetWidth;} for (var i = 0; i
También tengo una aplicación de consola que también se comunica con el Servicio WCF y la aplicación de la consola puede llamar a métodos finos sin obtener este error.
A continuación hay extractos de mis archivos de configuración.
WCF Service Web.Config:
<system.serviceModel>
<services>
<service name="ScraperService" behaviorConfiguration="ScraperServiceBehavior">
<endpoint address=""
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IScraperService"
contract="IScraperService" />
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://example.com" />
</baseAddresses>
</host>
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IScraperService"
bypassProxyOnLocal="false" transactionFlow="false"
hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="2000000" maxReceivedMessageSize="2000000"
messageEncoding="Text" textEncoding="utf-8"
useDefaultWebProxy="true" allowCookies="false">
<readerQuotas
maxDepth="2000000" maxStringContentLength="2000000"
maxArrayLength="2000000" maxBytesPerRead="2000000"
maxNameTableCharCount="2000000" />
<reliableSession
enabled="false" ordered="true" inactivityTimeout="00:10:00" />
<security mode="Message">
<message clientCredentialType="Windows"
negotiateServiceCredential="true"
algorithmSuite="Default"
establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ScraperServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Sitio web Project Service Client Web.Config
:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IScraperService"
closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="false"
hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8"
useDefaultWebProxy="true" allowCookies="false">
<readerQuotas
maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384" maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
<reliableSession enabled="false"
ordered="true" inactivityTimeout="00:10:00" />
<security mode="Message">
<transport clientCredentialType="Windows"
proxyCredentialType="None" realm="" />
<message clientCredentialType="Windows"
negotiateServiceCredential="true"
algorithmSuite="Default" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint name="WSHttpBinding_IScraperService"
address="http://example.com/ScraperService.svc"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IScraperService"
contract="ScraperService.IScraperService" >
<identity>
<servicePrincipalName value="host/FreshNET-II" />
</identity>
</endpoint>
</client>
</system.serviceModel>
Este es mi primer intento de crear un WCF, así que todo es muy nuevo. Cualquier ayuda es muy apreciada.
Gracias.
En mi caso, una regla de reescritura de URL estaba jugando con mi nombre de servicio, fue reescrita como minúscula y recibí este error.
Asegúrese de no hacer llamadas de servicio WCF en minúsculas.
En mi proyecto Serive de WCF, este problema se debe a la referencia de la versión diferente de System.Web.Mvc.dll. Por lo que puede ser problema de compatibilidad de la versión diferente de DLL
Cuando uso
System.Web.Mvc.dll versión 5.2.2.0 -> obtiene el error El tipo de contenido text / html; charset = utf-8 del mensaje de respuesta
pero cuando uso System.Web.Mvc.dll versión 4.0.0.0 o inferior -> funciona bien .
No sé el motivo del problema de la versión DLL diferente, pero al cambiar la versión de DLL funciona para mí.
Este error incluso se genera cuando agrega referencia de otro proyecto en su proyecto WCF y este proyecto de referencia tiene una versión diferente de System.Web.Mvc DLL o podría ser cualquier otra DLL.
Es posible que desee examinar la configuración de su servicio y asegurarse de que todo esté bien. Puede navegar al servicio web a través del navegador para ver si el esquema se procesará en el navegador.
Es posible que también desee examinar las credenciales utilizadas para llamar al servicio.
Incluso si no usa el proxy de red, al girar ''Detectar configuraciones automáticamente'' en el cuadro de diálogo proxy se activará esta excepción.
Intenté todas las sugerencias anteriores, pero lo que funcionó al final fue cambiar la canalización administrada del grupo de aplicaciones del modo integrado al modo clásico.
Se ejecuta en su propio grupo de aplicaciones, pero fue el primer servicio .NET 4.0, todos los otros servicios están en .NET 2.0 utilizando el modo de canalización integrada. Es solo un servicio WCF estándar que se usa es https - pero en Server 2008 (no R2) - usando IIS 7 (no 7.5).
Intente navegar a http://localhost/ScraperService.svc en el navegador web en el servidor que aloja el servicio, utilizando las mismas credenciales de Windows que el cliente normalmente ejecuta.
Imagino que IIS muestra un mensaje de error html de alguna descripción en lugar de devolver xml como se esperaba.
Esto también puede ocurrir cuando tiene un servidor proxy http que realiza el filtrado de Internet. Mi experiencia con ContentKeeper es que intercepta cualquier tráfico http / https y lo bloquea como "Contenido no administrado": todo lo que recibimos es un mensaje de error html. Para evitar esto, puede agregar reglas de excepción del servidor proxy a Internet Explorer para que el proxy no intercepte el tráfico a su sitio:
Panel de control> Opciones de Internet> Conexiones> Configuración de LAN> Avanzado> Configuración de proxy
Para mí, el problema se resolvió cuando comenté la siguiente línea en Web.config
<httpErrors errorMode="Detailed" />
Resolví este problema al establecer UseCookies en web.config.
<system.web>
<sessionState cookieless="UseCookies" />
y configurar enableVersionHeader
<system.web>
<httpRuntime targetFramework="4.5.1" enableVersionHeader="false" executionTimeout="1200" shutdownTimeout="1200" maxRequestLength="103424" />
Si está utilizando tanto wshttpbinding junto con la solicitud https, entonces lo resolví utilizando el siguiente cambio de configuración.
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" />
<message clientCredentialType="Certificate" />
</security>
Tuve un problema similar. Lo resolví cambiando
<basicHttpBinding>
a
<basicHttpsBinding>
y también cambié mi URL para usar https: // en lugar de http: //.
También en el nodo <endpoint>, cambie
binding="basicHttpBinding"
a
binding="basicHttpsBinding"
Esto funcionó.
Tuve una situación similar, pero la configuración del cliente estaba usando un basicHttpBinding. El problema resultó ser que el servicio estaba usando SOAP 1.2 y no puede especificar SOAP 1.2 en un basicHttpBinding. Modifiqué la configuración del cliente para usar un enlace personalizado y todo funcionó. Aquí están los detalles de mi CustomBinding para referencia. El servicio que intentaba consumir estaba sobre HTTPS usando UserNameOverTransport.
<customBinding>
<binding name="myBindingNameHere" sendTimeout="00:03:00">
<security authenticationMode="UserNameOverTransport" includeTimestamp="false">
<secureConversationBootstrap />
</security>
<textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
messageVersion="Soap12" writeEncoding="utf-8">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</textMessageEncoding>
<httpsTransport manualAddressing="false" maxBufferPoolSize="4194304"
maxReceivedMessageSize="4194304" allowCookies="false" authenticationScheme="Basic"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
keepAliveEnabled="true" maxBufferSize="4194304" proxyAuthenticationScheme="Anonymous"
realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
useDefaultWebProxy="true" requireClientCertificate="false" />
</binding>
</customBinding>
Una respuesta HTML del servidor web normalmente indica que se ha servido una página de error en lugar de la respuesta del servicio WCF. Mi primera sugerencia sería verificar que el usuario con el que está ejecutando el cliente WCF tenga acceso al recurso.
X ++ binding = endPoint.get_Binding(); binding.set_UseDefaultWebProxy(false);
binding = endPoint.get_Binding(); binding.set_UseDefaultWebProxy(false);
lo que está pasando es que estás tratando de acceder al servicio usando wsHttpBind, que usa mensajes cifrados seguros por defecto (mensajes seguros). Por otro lado, netTcpBind utiliza canales encriptados seguros. (Transporte seguro) ... PERO basicHttpBind, no requiere ninguna seguridad en absoluto, y puede acceder anónimo
ASI QUE. en el lado del servidor, agregue / Cambie esto en su configuración.
<bindings>
<wsHttpBinding>
<binding name="wsbind">
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
algorithmSuite="Default" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
a continuación, agregue cambiar su punto final a
<endpoint address="" binding="wsHttpBinding" bindingConfiguration="wsbind" name="wshttpbind" contract="WCFService.IService" >
Deberias hacer eso.