2

We have an application that is using a http binding that has this configuration on the client side:

    <binding name="SecureStreamedHttpBinding"
             transferMode="Streamed"
             maxReceivedMessageSize="8000000000"
             maxBufferSize="65536"
             sendTimeout="00:20:00">
      <security mode="Transport">
        <transport clientCredentialType="None" />
      </security>
    </binding>

And this configuration on the server side:

    <binding name="SecureStreamedHttpBinding_IHub"
             transferMode="Streamed"
             maxReceivedMessageSize="8000000000"
             maxBufferSize="65536"
             receiveTimeout="00:20:00">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
    </binding>

The channel is being open by the client by creating a ChannelFactory and then calling CreateChannel:

               ChannelFactory<IHub> channelFactory = new ChannelFactory<IHub>(endpointConfigurationName);
           IHub hub = channelFactory.CreateChannel();
           ((IClientChannel)hub).Open();

Sometimes when we try to transfer large files over this connection we get an error from the server that says: "The remote server returned an unexpected response: (413) Request Entity Too Large." I say sometimes because there seems to be a number of timing/speed factors that can cause the error to come and go. For instance errors seem more prevalent on machines with high bandwidth. They seem to be less prevalent when started well after the connection is established. The effects of timing/speed are inconsistent however.

If TLS is turned off we never have any issues.

We have Wire Sharked the connection and found that the client is sending a "FIN" message on the port at approximately the same time of the error, but we don't know exactly when the 413 error occurs because we don't see it in Wire Shark. So, we don't know if this is cause or effect.

We have also reviewed the Failed Request Tracing information from IIS and found the "Request Entity Too Large" listed along with the data that was being transferred at that time, but we are unsure how to interpret what we see.

We don't know why the client is issuing the FIN? Is that normal? Is it the cause of the "Request Entity Too Large" error on the server, or the other way around. Or just coincidence? Either way the effect is that we have to restart the file transfer at that point. Any thought on what might be the root cause of the error?

Thanks in advance for your help.

James R
  • 145
  • 2
  • 13
  • How big are the files being sent? What's the worst case scenario? What I'm getting at is your maxReceivedMessageSize or maxBufferSize – Bill Sambrone Mar 29 '16 at 20:05
  • The max file size is realistically around 4gb, but we wanted to set the limit to 8gb just in case. We set the max buffer size to 65536. One thing that we've seen is that setting the uploadReadAheadSize to a larger number is helpful, but you cannot set that larger than around 2gb, so that doesn't help with the really big files. – James R Mar 29 '16 at 20:47
  • One more note, even though the max file size we expect to transfer is 4gb, it is going to be binary encoded data which I believe will expand the file size to more than 5gb. – James R Mar 29 '16 at 20:51

1 Answers1

1

So, it's been a while since I've touched WCF but I think I found one possible thing. Your problem might not be WCF, but instead might be IIS. After doing some investigation, you might be running into issues with the SSL cert due to request size.

This other SO answer is a good read, although it only partially covers your issue:

IIS7 - (413) Request Entity Too Large | uploadReadAheadSize

If you're stuck, it may be worth a shot to enable client negotiation for the SSL on the IIS box. Copy/pasta code from the original link in case in goes down:

One of the causes listed in the error message states "The Web Server cannot service the request because it is trying to negotiate a client certificate but the request entity is too large". The resolution for that issue was to set the value of clientcertnegotiation=enable. Getting this set on IIS 7 was a bit involved. The following but be run via a command prompt:

netsh http show sslcert

NOTE You will need these settings for the next set of commands.

To delete the current settings (you cannot change existing settings, you have to delete and readd) netsh http delete sslcert :

The IP address and port are obtained from the show command results. Example: netsh http delete sslcert 0.0.0.0:443

To add the cert settings back in correctly: netsh http add sslcert ipport=: certhash= appid= certstorename= clientcertnegotiation=enable

Original article:

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

Also, take a look at increasing your upload read ahead size: http://www.iis.net/configreference/system.webserver/serverruntime

Community
  • 1
  • 1
Bill Sambrone
  • 4,334
  • 4
  • 48
  • 70
  • In my particular case only setting every option as decribed above solved the problem. I have also set limits as per https://weblog.west-wind.com/posts/2016/apr/06/configuring-aspnet-and-iis-request-length-for-post-data – Anton Krouglov Jun 28 '19 at 12:33