Служба WCF возвращает 404 по запросам метода

У меня есть страница сервиса WCF, работающая только с WebGets/WebInvokes через SSL - она отлично работает на моей локальной машине (самоподписанный сертификат). Однако при производстве я могу достичь service.svc(и он дает мне сообщение о том, как потреблять), но service.svc/AnyRequest возвращает 404. Обе среды размещены в IIS 7.5.

Я включил трассировку, и служба даже не подобрала ни одного из запросов метода (например, service.svc/SomeRequest), однако она отлично обрабатывает service.svc. Он также слушает в https://computername.domain.net/path/service.svc - это нормально? Если он обычно указывает на https://publicfacing.com/path/service.svc?

Также обратите внимание, что производственный сервер размещает несколько сайтов в IIS.

Ниже представлен раздел system.serviceModel моего web.config. SSLBehave был предложен из здесь.

  <system.serviceModel>
    <bindings>
      <webHttpBinding>
        <binding name="TransportSecurity">
          <security mode="Transport">
            <transport clientCredentialType="None"></transport>
          </security>
        </binding>
      </webHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="SSLBehave">
          <useRequestHeadersForMetadataAddress>
            <defaultPorts>
              <add scheme="https" port="443"/>
            </defaultPorts>
          </useRequestHeadersForMetadataAddress>
        </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="UserManagement.ajaxAspNetAjaxBehavior">
          <webHttp defaultOutgoingResponseFormat="Json" defaultBodyStyle="Wrapped" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
      multipleSiteBindingsEnabled="true" />
    <services>
      <service name="UserManagement.ajax" behaviorConfiguration="SSLBehave">
        <endpoint address="" behaviorConfiguration="UserManagement.ajaxAspNetAjaxBehavior"
          binding="webHttpBinding" bindingConfiguration="TransportSecurity" contract="UserManagement.ajax" />
      </service>
    </services>
  </system.serviceModel>

Ответ 1

Я бы начал с проверки нескольких вещей;

Права на размещенный каталог?
.Net версия верна?
Вы добавили сертификат на сайт?
Попробуйте помещать изображение в один и тот же путь, вы можете перейти к нему (исключить нечетные случайные сопоставления пути)

Удачи!

Ответ 2

Первое, что я делаю, когда сталкиваюсь с 404 с недавно разработанной веб-службой WCF, проверяет сопоставление обработчика, необходимое для интерпретации этого типа вызова, потому что это часто является причиной проблемы. Есть несколько способов обойти эту проблему, многие из которых требуют ручного выполнения консольной команды ServiceModelReg.exe: это, несомненно, допустимые процедуры, но они могут также не работать - или создавать дополнительные проблемы - если ваша машина разработки имеет особенно сложную конфигурацию, Метод разрешения, который я предлагаю ниже, требует немного больше времени, но имеет преимущество в том, что решение проблемы более безопасно и надежно.

Откройте интерфейс диспетчера серверов для управления машиной, который обычно присутствует как на панели задач, так и в меню "Пуск".
Перейдите на панель инструментов и выберите Добавить роль или функцию, чтобы открыть мастер.
Выберите тип установки на основе ролей или компонентов и сервер, на котором вы хотите работать, то есть локальный/локальный сервер.
Перейдите в раздел Компоненты. После этого разверните узел Компонентов.NET Framework 3.5 и/или узел .NET Framework 3.5 Features.NET Framework 3.5 в зависимости от того, что вы установили: если у вас есть оба, вы должны выполнить следующий шаг дважды (для каждого из них).
Разверните раздел Службы WCF (если он доступен), затем выберите Активация HTTP (см. снимок экрана ниже).
Продолжайте, пока не завершите работу мастера, затем нажмите Установить.

После завершения установки вы сможете запустить службу WCF без повторения ошибки 404.

Для получения дополнительной информации об этой конкретной проблеме и о том, как ее исправить, вы также можете прочитать этот пост в моем блоге.

Ответ 3

У меня была та же проблема. Из того, что я прочитал, WCF не является аутентифицированной авторизацией NT (или совместимой с HTTPContext).

Мне пришлось добавить это в мой файл конфигурации для службы WCF web.config в разделе:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>

Что вы сделали, плюс это:

И при фактическом определении класса обслуживания мне пришлось добавить:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class DataService : IDataDeliveryServiceContract

Это исправило мою проблему.

Ответ 4

Вы можете реализовать безопасность транспортного уровня, используя привязки WsHttp. См. в этой статье; в ваших привязках попробуйте это предложение вместо:

<wsHttpBinding>
<binding name="TransportSecurity">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</wsHttpBinding>

В статье упоминается, что вы должны привязать привязки к конечным точкам.

Ответ 5

Возможно, в вашем файле RouteConfig.cs добавьте эту строку:

routes.IgnoreRoute("{resource}.svc/{*pathInfo}");

Пока ваш .svc файл находится в корне приложения.

Ответ 6

Как вы уже сказали, вы можете получить доступ к своей службе с помощью расширения .svc service.svc, но не в формате REST service.svc/AnyRequest, проблема должна быть в интеграции маршрутизации.

добавьте это в свой web.config

 <system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </modules>
  <handlers>
    <add name="UrlRoutingHandler" preCondition="integratedMode" verb="*" path="UrlRouting.axd"/>
  </handlers>
 </system.webServer>

В IIS 6 Причиной этой ошибки должно быть значение Check that file exists для расширения svc, убедитесь, что "Проверить, что файл существует, не установлен". Для получения дополнительной информации см. IIS Hosted Service Fails.

Ответ 7

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

Ответ 8

Следующий параметр в файле web.config исправил WCF.svc 404 на веб-сайте HTTPS:

      <webHttpBinding>
             <!-- https -->
             <security mode="Transport">
                    <transport clientCredentialType = "None" proxyCredentialType="None"/>
            </security>
    </binding>
  </webHttpBinding>