WCF application retour 400 Bad Request lorsque hébergé sur IIS7

Question

J'ai écrit un service Web WCF en utilisant C# et Visual Studio 2008.

Lorsque je le lance en utilisant le construit dans le serveur Web de développement, je suis en mesure de voir les résultats des différentes méthodes en accédant à l'URL spécifiée dans l'attribut [WebGet (UriTemplate = "..")] du contrat de service.

Plus précisément, j'ai une méthode qui correspond à l'URL "/", et retourne un fichier HTML brut.

Toutefois, lorsque je déploie sur IIS, sous Windows Server 2008, cette méthode renvoie la page standard "Vous avez créé un service".

Si je tente d'exécuter l'un de mes autres méthodes, en utilisant les modèles URI I spécifiés, par exemple:

api.hostname.com/Service.svc/method/param 

Le serveur renvoie 400 Bad Request.

La section system.serviceModel de mon web.config direct ressemble à ceci:

<system.serviceModel> 
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> 
    <services> 
     <service name="RootNamespace.Api.EventService" 
      behaviorConfiguration="RootNamespace.Api.EventServiceBehaviour" > 
     <endpoint address="" 
        binding="wsHttpBinding" 
        contract="RootNamespace.Api.IEventService" /> 
     <endpoint address="mex" 
        binding="mexHttpBinding" 
        contract="IMetadataExchange" /> 
     <host> 
      <baseAddresses> 
      <add baseAddress="http://api.hostname.com" /> 
     </baseAddresses> 
     </host> 
    </service> 
    </services> 
    <behaviors> 
    <serviceBehaviors> 
     <behavior name="RootNamespace.Api.EventServiceBehaviour"> 
     <serviceMetadata httpGetEnabled="true" /> 
     <serviceDebug includeExceptionDetailInFaults="true" /> 
     </behavior> 
    </serviceBehaviors> 
    </behaviors> 
</system.serviceModel> 

Je me suis demandé si la demande ne recevait pas aussi loin que le service WCF, et a été bloqué par un autre gestionnaire dans IIS mais le fait qu'il retourne un contenu différent pour l'URL racine me conduit à soupçonner que je fais quelque chose d'autre ici.

Mise à jour ...

j'ai réussi à progresser légèrement avec un web.config révisé:

<behaviors> 
    <serviceBehaviors> 
    <behavior name="RootNamespace.Api.EventServiceBehavior"> 
     <serviceMetadata httpGetEnabled="false" /> 
     <serviceDebug includeExceptionDetailInFaults="true" /> 
    </behavior> 
    </serviceBehaviors> 
    <endpointBehaviors> 
    <behavior name="WebBehavior"> 
     <webHttp/> 
    </behavior> 
    </endpointBehaviors> 
</behaviors> 

<services> 
    <service behaviorConfiguration="RootNamespace.Api.EventServiceBehavior" 
      name="RootNamespace.Api.EventService"> 
    <endpoint address="" 
       binding="webHttpBinding" 
       behaviorConfiguration="WebBehavior"      
       contract="RootNamespace.Api.IEventService"> 
    </endpoint> 
    </service> 
</services> 

Ceci est évidemment très différent de ma première tentative , mais l'objectif reste le même: je souhaite utiliser un navigateur Web pour accéder aux URL définies dans les attributs WebGet de m y contrat de service (IEventService). En utilisant cette configuration Web, plutôt que d'obtenir une erreur 400, je reçois maintenant une erreur 403 interdite pour les méthodes que j'ai définies. Pour les méthodes qui n'existent pas, je reçois correctement un message 'Endpoint not found'. Cela me fait penser que j'ai des choses fonctionnant correctement mais que je souffre juste d'une sorte de problème d'authentification au niveau de la couche application. J'ai également l'impression que je rends cela trop compliqué. Cela fonctionne sans aucun type de configuration dans le serveur Web Visual Studio après tout.

Answer 1

Je pense que votre problème est le suivant:

• si vous avez des métadonnées de service activé et ont le httpGetEnabled=true dans votre config (et vous), puis en appuyant l'adresse de base (baseAddress="http://api.seetickets.com") rendra sur les métadonnées page "vous avez un service". C'est le comportement WCF par défaut.

• vous avez une page html intro qui "vit" à la même adresse -> vous avez un conflit

Vous pouvez faire deux choses, vraiment:

• désactiver le httpGetEnabled sur vos métadonnées de service

ou:

• déplacez votre page d'introduction vers une autre adresse, par ex. http://api.seetickets.com/intro ou quelque chose (en définissant le UriTemplate="....." sur la méthode de service)