Client de service WCF: Le type de contenu text/html; charset = utf-8 du message de réponse ne correspond pas au type de contenu de la liaison
Un service WCF est en cours d'exécution sur mon serveur IIS local. Je l'ai ajouté en tant que référence de service à un projet de site Web C #. Il ajoute très bien et génère les classes de proxy automatiquement.
Cependant, lorsque j'essaie d'appeler l'un des contrats de service, l'erreur suivante apparaît:
Description: Une exception non gérée s'est produite lors du exécution de la requête Web en cours . Veuillez vérifier la trace de la pile pour plus d'informations informations sur l'erreur et où cela provient du code.
Détails des exceptions: System.ServiceModel.ProtocolException: Le type de contenu text/html; charset = utf-8 du message de réponse ne correspond pas au type de contenu du fichier binding (application/soap + xml; charset = utf-8). Si vous utilisez une coutume codeur, assurez-vous que le La méthode IsContentTypeSupported est mis en œuvre correctement. Le premier 1024 Les octets de la réponse étaient: ' une fonction bredir (d, u, r, v, c) {var w, h, wd, hd, bi; var b = faux; var p = faux; var s = [[[300,250, faux], [250,250, faux], [240,400, faux], [336,280, faux], [180,150, faux], [468,60, faux], [234,60, faux], [ 88,31, faux], [120,90, faux], [120,60, faux], [120,240, faux], [125,125, faux], [728,90, faux], [160,600, faux], [ 120 600, faux], [300,600, faux], [300,125, faux], [530,300, faux], [190,200, faux], [470,250, faux], [720 300, vrai], [500 000, vrai], [550,480, true]]; if (typeof (window.innerHeight) == 'nombre') {h = window.innerHeight; w = window.innerWidth;} else if (typeof (document.body.offsetHeight) == 'numéro') {h = document.body.offsetHeight; w = document.body.offsetWidth;} pour (var i = 0; i
J'ai également une application console qui communique également avec le service WCF et l'application console est capable d'appeler des méthodes correctement sans obtenir cette erreur.
Vous trouverez ci-dessous des extraits de mes fichiers de configuration.
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>
Client du service de projet de site Web 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>
Ceci est ma première tentative de créer une WCF, donc tout est nouveau. Toute aide est très appréciée.
Essayez de naviguer vers http: //localhost/ScraperService.svc dans le navigateur Web sur le serveur hébergeant le service, en utilisant les mêmes informations d'identification Windows sous lesquelles le client s'exécute normalement.
J'imagine que IIS affiche un message d'erreur HTML contenant une description au lieu de renvoyer xml comme prévu.
Cela peut également se produire lorsque vous avez un serveur proxy http qui effectue un filtrage Internet. D'après mon expérience, ContentKeeper intercepte tout trafic http/https et le bloque en tant que "Contenu non géré" - tout ce que nous récupérons est un message d'erreur html. Pour éviter cela, vous pouvez ajouter des règles d'exception de serveur proxy à Internet Explorer afin que le proxy n'intercepte pas le trafic sur votre site:
Panneau de configuration> Options Internet> Connexions> Paramètres réseau> Avancé> Paramètres proxy
Une réponse HTML du serveur Web indique normalement qu'une page d'erreur a été générée au lieu de la réponse du service WCF. Ma première suggestion serait de vérifier que l'utilisateur sous lequel vous exécutez le client WCF a accès à la ressource.
J'ai eu un problème similaire. Je l'ai résolu en changeant
<basicHttpBinding>
à
<basicHttpsBinding>
et également changé mon URL pour utiliser https: // au lieu de http: //.
Toujours dans le noeud <noeud final>, changez
binding="basicHttpBinding"
à
binding="basicHttpsBinding"
Cela a fonctionné.
en réalité, vous essayez d'accéder au service à l'aide de wsHttpBind, qui utilise par défaut des messages cryptés sécurisés (messages sécurisés) . D'autre part, netTcpBind utilise des canaux cryptés sécurisés. (Transport sécurisé) ... MAIS basicHttpBind, ne nécessite aucune sécurité, et peut accéder de manière anonyme
ALORS. côté serveur, ajoutez\changez ceci dans votre configuration.
<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>
puis ajoutez changer votre point de terminaison à
<endpoint address="" binding="wsHttpBinding" bindingConfiguration="wsbind" name="wshttpbind" contract="WCFService.IService" >
Ça devrait le faire.
Vous voudrez peut-être examiner la configuration de votre service et vous assurer que tout va bien. Vous pouvez accéder au service Web via le navigateur pour voir si le schéma sera rendu sur le navigateur.
Vous pouvez également vouloir examiner les informations d'identification utilisées pour appeler le service.
Même si vous n'utilisez pas de proxy réseau, l'activation de «Détecter automatiquement les paramètres» dans la boîte de dialogue du proxy provoque la désactivation de cette exception.
Dans mon projet de série WCF, ce problème est dû à la référence de la version différente de System.Web.Mvc.dll. Donc, il peut être un problème de compatibilité de la version différente de DLL
Quand j'utilise
System.Web.Mvc.dll version 5.2.2.0 -> il relève le Erreur Le type de contenu text/html; charset = utf-8 du message de réponse
mais quand j’utilise System.Web.Mvc.dll version 4.0.0.0 ou inférieure -> ça fonctionne très bien .
Je ne connais pas la raison du problème de la version différente de DLL, mais en changeant la version de la DLL, cela fonctionne pour moi.
Cette erreur est même générée lorsque vous ajoutez une référence à un autre projet dans votre projet WCF et que ce projet de référence a une version différente de System.Web.Mvc DLL ou peut être une autre DLL.
Comme beaucoup, dans ma situation, je l’obtenais aussi à cause d’une erreur. Et malheureusement, je n'ai pu lire que le code CSS de la page d'erreur HTML.
La source de mon problème était également une règle de réécriture sur le serveur. Il était en train de réécrire http en https.
J'ai eu une situation similaire, mais la configuration du client utilisait un basicHttpBinding. Le problème s'est avéré que le service utilisait SOAP 1.2 et vous ne pouvez pas spécifier SOAP 1.2 dans un basicHttpBinding. J'ai modifié la configuration du client pour utiliser un customBinding à la place et tout a fonctionné. Voici les détails de mon customBinding pour référence. Le service que j'essayais de consommer était via HTTPS avec 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>
J'ai essayé toutes les suggestions ci-dessus, mais ce qui a bien fonctionné a été de faire passer le pipeline géré du pool d'applications du mode intégré au mode classique.
Il fonctionne dans son propre pool d’applications - mais c’était le premier service .NET 4.0 - tous les autres services sont sur .NET 2.0 en mode pipeline intégré . C’est un service WCF standard qui utilise https - 2008 (pas R2) - utilisant IIS 7 (pas 7.5).
Dans mon cas, une règle de réécriture d'URL était en désordre avec le nom de mon service. Elle était réécrite en minuscule et je recevais cette erreur.
Assurez-vous de ne pas utiliser d'appels de service WCF minuscules.
Si vous utilisez à la fois wshttpbinding et la requête https, alors je l’ai résolu en utilisant la modification de configuration ci-dessous.
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" />
<message clientCredentialType="Certificate" />
</security>
REMARQUE: Si le noeud final du serveur cible utilise un certificat SSL (Secure Socket Layer)
Modifiez votre paramètre .config de basicHttpBinding à basicHttpsBinding
Je suis sûr que cela résoudra votre problème.
J'ai résolu ce problème en définissant UseCookies dans web.config.
<system.web>
<sessionState cookieless="UseCookies" />
et paramétrage de enableVersionHeader
<system.web>
<httpRuntime targetFramework="4.5.1" enableVersionHeader="false" executionTimeout="1200" shutdownTimeout="1200" maxRequestLength="103424" />
Hy, Dans mon cas, cette erreur est apparue car le pool d'applications du service Web avait le mauvais paramètre 32/64 bits. Cette erreur nécessitait donc le correctif suivant: vous accédez à IIS, sélectionnez le site du service Web, accédez au paramètre Avancé et récupérez le pool d’applications. Ensuite, allez dans Pools d'applications, sélectionnez-le, allez dans "Paramètres avancés ...", sélectionnez l'option "Activer les applications 32 bits" et activez-la en fonction du type 32/64 bits de votre service Web . Si le paramètre est True, cela signifie qu'il n'autorise que les applications 32 bits. Par conséquent, pour les applications 64 bits, vous devez le rendre "Désactiver" (par défaut).
Pour moi, le problème a été résolu lorsque j'ai commenté la ligne suivante dans Web.config.
<httpErrors errorMode="Detailed" />
X ++ binding = endPoint.get_Binding();
binding.set_UseDefaultWebProxy(false);
Pour moi, c'était la chaîne de connexion de l'application Web qui pointait vers le mauvais serveur de base de données.