更新：

Question

关于这个问题有很多讨论，但我现在已经尝试了所有可能的解决方案，我们仍然从服务器获得413个请求实体太大的错误。

我们的WCF服务是通过Azure辅助角色自托管的，不使用IIS。我们的所有配置都在代码中指定：

var host = new ServiceHost(searchEngine);

// Create binding
var binding = new WebHttpBinding(WebHttpSecurityMode.Transport);

binding.MaxReceivedMessageSize = 2147483647;
binding.MaxBufferSize = 2147483647;
binding.MaxBufferPoolSize = 2147483647;

var readerQuotas = new XmlDictionaryReaderQuotas
{
    MaxStringContentLength = 2147483647,
    MaxArrayLength = 2147483647,
    MaxBytesPerRead = 2147483647,
    MaxDepth = 2147483647,
    MaxNameTableCharCount = 2147483647
};

// Setting quotas on a BindingElement after the binding is created has no effect on that binding.
// See: https://stackoverflow.com/questions/969479/modify-endpoint-readerquotas-programatically
binding.GetType().GetProperty("ReaderQuotas").SetValue(binding, readerQuotas, null);

binding.ReceiveTimeout = new TimeSpan(1, 0, 0);
binding.SendTimeout = new TimeSpan(1, 0, 0);

// Add the service endpoint
var ep = host.AddServiceEndpoint(
    typeof(ISearchEngine),
    binding,
    string.Format("https://{0}/SearchEngine", externalEndpoint));

ep.Behaviors.Add(new WebHttpBehavior());

// Increase the MaxItemsInObjectGraph quota for all operations in this service
foreach (var operation in ep.Contract.Operations)
{
    operation.Behaviors.Find<DataContractSerializerOperationBehavior>().MaxItemsInObjectGraph = 10000000;
}

return host;

这是我们的客户端配置 - 也在代码中指定：

var binding = new WebHttpBinding(WebHttpSecurityMode.Transport);

binding.MaxReceivedMessageSize = 2147483647;
binding.MaxBufferSize = 2147483647;
binding.MaxBufferPoolSize = 2147483647;

var readerQuotas = new XmlDictionaryReaderQuotas
{
    MaxStringContentLength = 2147483647,
    MaxArrayLength = 2147483647,
    MaxBytesPerRead = 2147483647,
    MaxDepth = 2147483647,
    MaxNameTableCharCount = 2147483647
};

// Setting quotas on a BindingElement after the binding is created has no effect on that binding.
// See: https://stackoverflow.com/questions/969479/modify-endpoint-readerquotas-programatically
binding.GetType().GetProperty("ReaderQuotas").SetValue(binding, readerQuotas, null);

binding.ReceiveTimeout = new TimeSpan(1, 0, 0);
binding.SendTimeout = new TimeSpan(1, 0, 0);

binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;

var channelFactory = new ChannelFactory<ISearchEngine>(binding, endpointAddress);

channelFactory.Endpoint.Behaviors.Add(new WebHttpBehavior());


// Increase the MaxItemsInObjectGraph quota for all operations in this service
foreach (var operation in channelFactory.Endpoint.Contract.Operations)
{
    operation.Behaviors.Find<DataContractSerializerOperationBehavior>().MaxItemsInObjectGraph = 10000000;
}

return channelFactory.CreateChannel();

我唯一的预感可能是SSL连接有问题吗？有些文章提到了IIS特有的问题，但是我不确定这是否与自托管服务相关。

非常感谢任何建议。

更新：

为了确认我的预感是SSL是问题，我暂时禁用了SSL并且看到问题消失了。

所以现在我需要弄清楚为什么SSL会导致问题。有一些关于类似问题的文档，但它只与IIS托管服务有关（我们的是从Windows服务自托管）：

IIS7 - (413) Request Entity Too Large | uploadReadAheadSize

那里的任何人都知道仅适用于自托管WCF服务的等效设置吗？

Answer 1

我找到了问题，感谢这个看似无关的帖子：

http://forums.newatlanta.com/messages.cfm?threadid=554611A2-E03F-43DB-92F996F4B6222BC0&#top

这绝对是一个SSL问题，它与将SSL证书绑定到您托管的端口有关。您必须使用netsh绑定证书，并将 clientcertnegotiation = enable 添加到绑定。

在我们的例子中，我们已经使用了netsh，因为我们使用的是另一个端口，所以我们的绑定现在看起来像这样：

netsh http add sslcert ipport=0.0.0.0:10100 certhash=000000089A6679262D845B650FDDE5390F0D86AB appid={000007b4-2d4b-4587-ae99-7a6627476f76} clientcertnegotiation=enable

对于那些通过IIS托管并更改UploadReadAheadSize值的人，上面的论坛帖子指出这可能会导致高CPU，而这个解决方案可能更好。

Answer 2

如果您需要传输大数据，则应使用transferMode =“Streaming”。

看看MS的这篇论文：

http://msdn.microsoft.com/en-us/library/ms733742(v=vs.110).aspx

WCF 413请求实体太大 - 自托管WebHttpBinding

更新：

2 个答案: