Приложение WCF, возвращающее 400 неверных запросов при размещении на IIS7 - PullRequest
0 голосов
/ 20 июля 2010

Я написал веб-сервис WCF с использованием C # и Visual Studio 2008.

Когда я запускаю его с помощью встроенного веб-сервера разработки, я могу просмотреть результаты различных методов, перейдя по URL-адресу, указанному в атрибуте [WebGet (UriTemplate = "..")] контракта на обслуживание. .

В частности, у меня есть метод, который соответствует URL "/" и возвращает простой HTML-файл.

Однако при развертывании в IIS под управлением Windows Server 2008 этот метод возвращает стандартную страницу «Вы создали службу».

Если я пытаюсь выполнить любой из моих других методов, используя указанные вами шаблоны URI, например:

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

Сервер возвращает 400 неверных запросов.

Раздел system.serviceModel моего живого web.config выглядит следующим образом:

 <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>

Я задавался вопросом, не был ли запрос настолько же далеким, как служба WCF, и был ли заблокирован другим обработчиком в IIS, но тот факт, что он возвращает другое содержимое для корневого URL, заставляет меня подозревать, что я делаю что-то еще здесь не так.

Обновление ...

Мне удалось немного продвинуться с исправленным web.config:

<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>

Это, очевидно, значительно отличается от моей первой попытки, однако цель остается той же - я хочу использовать веб-браузер для перехода к URL-адресам, определенным в атрибутах WebGet моего контракта на обслуживание (IEventService).

Используя эту веб-конфигурацию, вместо получения ошибки 400, теперь я получаю ошибку 403 для определенных мной методов. Для методов, которые не существуют, я правильно получаю сообщение «Конечная точка не найдена». Это заставляет меня думать, что у меня все работает правильно, но я просто страдаю от какой-то проблемы аутентификации на прикладном уровне.

Мне также кажется, что я делаю это слишком сложным. Это работает без какой-либо конфигурации на веб-сервере Visual Studio.

1 Ответ

0 голосов
/ 20 июля 2010

Я думаю, что ваша проблема заключается в следующем:

  • , если у вас включены метаданные службы и у вас есть httpGetEnabled=true в вашей конфигурации (и у вас есть), тогда нажмите базовый адрес (baseAddress="http://api.seetickets.com") отобразит страницу метаданных "у вас есть услуга".Это поведение WCF по умолчанию.

  • у вас есть вступительная html-страница, которая "живет" по тому же адресу -> у вас конфликт

На самом деле вы можете сделать две вещи:

  • отключить httpGetEnabled в метаданных вашей службы

или:

  • переместить ваше вступлениестраницу по другому адресу, например http://api.seetickets.com/intro или что-то еще (установив UriTemplate="....." в методе обслуживания)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...