Ответ службы WCF «HTTP / 1.1 400 Bad Request» на общем хостинге <пустая страница, ошибка синтаксического анализа XML, неправильный адрес, веб-страница не найдена>

Question

Это информация как для тех, кто испытывает проблему, так и для вопроса.

edit: Вопрос в том, почему выбрасывается "www".из URL-адреса вызывают эту ошибку, когда на веб-сайт, работающий по тому же адресу, можно ссылаться без «www.».

Я недавно воспроизвел эту проблему, используя тривиальный сервис WCF (один из endpoint.tv)после решения обычных проблем с конфигурацией возникает проблема с перемещением службы с локального IIS на общий хостинг.

Проблема заключалась в следующем ответе (от fiddler) при проверке URL-адреса в браузере. При поискеВ сети для сообщений по этой теме я обнаружил ряд нерешенных проблем, указывающих на ту же проблему, в дополнение к сообщениям, в которых исправлены обычные проблемы конфигурации общего хостинга.

HTTP / 1.1 400 Bad Request Сервер: Microsoft-IIS / 7.0 X-Powered-By: ASP.NET Дата: Вторник, 17 августа 2010 г. 00:27:52 GMT Длина контента: 0

В Safari / Chrome это проявляется какпустая страница.

В IE вы получаете «Веб-страница не найдена».

В FF вы получаете «Ошибка синтаксического анализа XML: элемент не найден Расположение: http: // ................ Номер строки 1, столбец 1: «(что я видел в многочисленных неразрешенных постах в Интернете - не стесняйтесь ссылаться на возможное решение)

В Opera вы получаете« Неверный адрес »

Я царапал свойПодумайте об этом на некоторое время, затем я подумал , вставив "www".который я ранее пропускал из своего URL-адреса без особой причины.

Проблема решена.

Теперь я вижу нормальный вывод в браузере и взаимодействую сслужба через тестового клиента WCF.

Итак, вопрос:

Почему это имеет значение для размещенной службы WCF когда я знаю, что это не имеет значения для просмотра веб-сайта, размещенного по тому же адресу? С или без "www."Я могу перейти на веб-сайт в том же домене, размещенный на той же учетной записи.

До сих пор я тестировал это репродукцию на сервисе GoDaddy.Я могу попробовать некоторые другие позже.

Кроме того, если вам случится знать - мне было бы интересно узнать, какие функции могут сделать мои службы WCF нуждающимися в полном доверии, а не в среднем.И любые ваши мысли о том, является ли хорошей идеей использовать такие функции (в контексте идеологии наименьшего секрета).

Для справки это web.config, включая дополнительную конечную точку, предложенную Майком, чтобы попробовать ирешить эту проблему.

<?xml version="1.0"?>
<configuration>

  <system.web>
    <customErrors mode="Off"/>
    <compilation><!--debug="true"-->
        <buildProviders>
          <remove extension=".svc"/>
          <add extension=".svc" type="System.ServiceModel.Activation.ServiceBuildProvider,System.ServiceModel, Version=3.0.0.0, Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
        </buildProviders>
    </compilation>
  </system.web>

  <!-- When deploying the service library project, the content of the config file must be added to the host's 
  app.config file. System.Configuration does not support config files for libraries. -->
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="blah" 
               name="WCFServ.EvalService">
        <endpoint address="http://www.abcdomain.com/WCFServ/WCFServ.EvalService.svc" 
                  binding="basicHttpBinding" 
                  contract="WCFServ.IEvalService" />
        <endpoint address="http://abcdomain.com/WCFServ/WCFServ.EvalService.svc"
                  binding="basicHttpBinding"
                  contract="WCFServ.IEvalService" />
        <!--<endpoint address="" 
                  binding="mexHttpBinding" 
                  contract="IMetadataExchange" />-->
        <!--<host>
          <baseAddresses>
            <add baseAddress="http://abcdomain.com/WCFServ/" />
          </baseAddresses>
        </host>-->
      </service>
    </services>


    <behaviors>
      <serviceBehaviors>
        <behavior name="blah">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>

    <serviceHostingEnvironment>
      <baseAddressPrefixFilters>
        <add prefix="http://www.abcdomain.com/WCFServ/"/>
      </baseAddressPrefixFilters>
    </serviceHostingEnvironment>

  </system.serviceModel>




  <!--http://localhost/WCFServ/WCFServ.EvalService.svc-->

<startup><supportedRuntime version="v2.0.50727"/></startup></configuration>

Answer 1

Поскольку вы используете абсолютные URL-адреса в качестве адресов конечных точек, WCF должен видеть определенный заголовок хоста в HTTP-запросах, чтобы связываться с этими адресами.

Веб-серверы ничем не отличаются;если они настроены для конкретного хоста, заголовки запроса должны иметь имя хоста, иначе они не будут обслуживать контент.Однако к веб-сайтам можно привязать несколько имен хостов, поэтому иногда сайт может быть привязан как к www.example.com, так и к example.com.Кроме того, некоторые веб-браузеры, если вы зайдете на example.com и получите 404 или если поиск DNS не удастся, автоматически повторят запрос на www.example.com.Чтобы решить вашу проблему, нужно изменить конечные точки, чтобы они были нейтральными для хоста.Например:

<services>
  <service behaviorConfiguration="blah" name="WCFServ.EvalService">
    <endpoint address="/WCFServ/WCFServ.EvalService.svc" 
              binding="basicHttpBinding" 
              contract="WCFServ.IEvalService"/>
  </service>
</services>

<!-- Just leave this out
<serviceHostingEnvironment>
  <baseAddressPrefixFilters>
    <add prefix="http://www.abcdomain.com/WCFServ/"/>
  </baseAddressPrefixFilters>
</serviceHostingEnvironment>
-->

Answer 2

На этой странице есть несколько хороших объяснений по поводу адресации WCF: WCF Адресация в глубину .

Решена ли ваша проблема путем добавления следующего атрибута в ваш класс обслуживания?

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]

Answer 3

Убедитесь, что в вашей веб-конфигурации определены конечные точки без www.