使用Windows身份验证调用WCF服务时无法执行URL

我在将WCF服务部署到的一台服务器（它是Windows Server 2008 R2计算机）上使用Windows身份验证时遇到问题，而它在我可以访问的所有其他计算机（Windows 7、Windows Server 2008和Windows Server 2008 R2）上都能正常工作。我设法用一个非常简单的示例应用程序重现了这个问题，这个示例应用程序或多或少完全排除了我的代码是问题的原因

我可以复制该问题的最低应用程序是对WCF服务项目模板的轻微修改：

[ServiceContract]
public interface IService1
{
    [OperationContract]
    string GetData(int value);
}

[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class Service1 : IService1
{
    public string GetData(int value)
    {
        return string.Format("You entered: {0}\nUsername: {1}", 
            value, 
            ServiceSecurityContext.Current == null ? 
                "<null>" : 
                ServiceSecurityContext.Current.PrimaryIdentity.Name);
    }
}

请注意两个端点：一个具有默认地址，另一个具有相对地址。即使在有问题的服务器上，调用第一个也会成功，而调用第二个会失败，并出现以下错误：

Exception type: HttpException 
Exception message: Failed to Execute URL.
at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.BeginExecuteUrl(String url, String method, String childHeaders, Boolean sendHeaders, Boolean addUserIndo, IntPtr token, String name, String authType, Byte[] entity, AsyncCallback cb, Object state)
at System.Web.HttpResponse.BeginExecuteUrlForEntireResponse(String pathOverride, NameValueCollection requestHeaders, AsyncCallback cb, Object state)
at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

只有在使用经典管道时调用才会失败（我需要它是因为HttpHandler，但即使没有它，问题也可以重现）。集成管道解决了这个问题。此外，如果禁用Windows身份验证，问题也会消失：

<binding name="HttpBinding" maxReceivedMessageSize="2147483647">
  <readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647"/>
  <security mode="None">
    <transport clientCredentialType="None" />
  </security>
</binding>

我注意到注册了HttpHandler的另一个细节。具有相对地址的终结点的HttpRequest.CurrentExecutionFilePath属性的值在有问题的服务器（

~/Service1.svc/problem

）和工作服务器（

~/Service1.svc

）之间不同。虽然我对IIS不是很熟悉，但我怀疑这可能暗示了问题的原因——可能与请求路由有关

---

我的想法快用完了，所以我把这篇文章贴在这里，希望有人能认识到问题可能是什么。欢迎任何建议。

问题可能是地址“~/Service1.svc/problem”

当地址为“~/Service1.svc”时，调用将命中svc文件，并使用文件中的信息查找接口，然后查找该接口的配置

当您使用没有svc文件的相对地址时，它会查看配置文件中的地址

---

您是否在其中一台服务器上有目录“Service1.svc”，或者该地址在其工作的服务器上没有“.svc”？

您是否启用了IIS上的URL重写功能？这闻起来像是某种许可问题。可能会有帮助

都不是。在为测试目的进行故障排除期间，我在所有服务器上创建了一个新的应用程序，其中只包含上述测试项目中的文件：

Service1.svc

，

Web.config

，

bin\TestService.dll

。是否启用了IIS上的URL重写？这闻起来像是某种许可问题。可能会有帮助。@PetarVucetin我已检查，但服务器上未启用URL重写。虽然你的评论没有完全回答我的问题，但你提供的链接给了我一些想法——我设法重新配置了我的应用程序，使其能够在集成管道模式下工作，而在集成管道模式下问题不会显现出来。我仍然想知道如何使它在经典管道模式下工作，但如果我没有得到更好的答案来澄清这一点，你的评论是最好的悬赏候选人。毕竟，这确实让我解决了眼前的问题。谢谢达米尔。当我有时间时，我可以试着重新讨论这个问题。这简直让我发痒…@PetarVucetin赏金快到期了。你仍然是我获得该奖项的最佳候选人，但你需要添加一个答案，因为我无法将其授予评论。感谢链接。它让我了解了这些差异，最后我设法让我的应用程序在集成管道模式下工作。不过，我仍然很好奇，为什么它不能在该服务器上以经典管道模式工作。

<binding name="HttpBinding" maxReceivedMessageSize="2147483647">
  <readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647"/>
  <security mode="None">
    <transport clientCredentialType="None" />
  </security>
</binding>