HTTP 413 Request Entity Too Large In Self-Hosting WCF Service

Question

I have a self-hosting WCF service accepting messages via HTTPS.

A message is being sent from a Java application, which receives the response:

HTTP/1.1 413 Request Entity Too Large
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Date: Wed, 19 Sep 2012 09:05:34 GMT
Connection: close

I am not attempting to upload a file, just send an XML/SOAP message, which is 78kb. I have tried upping my max message and buffer sizes but to no avail.

  <binding name="SecuredNoProxy" openTimeout="00:00:10" sendTimeout="00:00:10">
      <textMessageEncoding messageVersion="Soap11WSAddressing10" />
      <security includeTimestamp="true" enableUnsecuredResponse="true">
          <localClientSettings timestampValidityDuration="00:15:00" />
      </security>
      <httpsTransport manualAddressing="false" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" allowCookies="false" bypassProxyOnLocal="true" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true" realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="false" requireClientCertificate="true" />
  </binding>

Please let me know if I can supply any additional information.

WCF Trace Log

Receive bytes on connection 'https://localhost'

Activity boundary (Start)

Connection information

Throwing an exception (Error)

The exception is:

System.ServiceModel.ProtocolException, System.ServiceModel, Version=4.0.0.0, Culture=neutral

Answer 1

As I eluded to in the question, this is very much related to the binding configurations. In particular, maxReceivedMessageSize.

maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647"

This is the correct area to change (probably not to make things quite this big though as it will leave you potentially vulnerable to denial of service attacks). Determine a sensible value based on your actual messages.

The outbound endpoint was correctly configured but the inbound endpoint wasn't - it was:

<httpsTransport requireClientCertificate="true" />

Which meant it was using the default value of 65536, which isn't enough for the message being sent. So it is really a case of checking the endpoints really carefully, especially if they are similarly named.