(413) Request Entity Too Large | uploadReadAheadSize

Question

I've written a WCF service with .NET 4.0, which is hosted on my Windows 7 x64 Ultimate system with IIS 7.5. One of the service methods has an 'object' as argument and I'm trying to send a byte[] which contains a picture. As long as the file size of this picture is less then approx. 48KB, all goes well. But if I'm trying to upload a larger picture, the WCF service returns an error: (413) Request Entity Too Large. So ofcourse I've spent 3 hours Googling the error message and every topic I've seen about this subject suggests raising the 'uploadReadAheadSize' property. So what I've done is using the following commands (10485760 = 10MB):

"appcmd.exe set config -section:system.webserver/serverruntime/uploadreadaheadsize: 10485760 /commit:apphost"

"cscript adsutil.vbs set w3svc/<APP_ID>/uploadreadaheadsize 10485760"

I've also used IIS Manager to set the value by opening the site and going to "Configuration Editor" under Management. Unfortunately I'm still getting the Request Entity Too Large error and it's getting really frustrating!

So does anybody know what else I can try to fix this error?

Angle

10485760 = 10MB, not 1MB – Bilabial

Answer 1

That is not problem of IIS but the problem of WCF. WCF by default limits messages to 65KB to avoid denial of service attack with large messages. Also if you don't use MTOM it sends byte[] to base64 encoded string (33% increase in size) => 48KB * 1,33 = 64KB

To solve this issue you must reconfigure your service to accept larger messages. This issue previously fired 400 Bad Request error but in newer version WCF started to use 413 which is correct status code for this type of error.

You need to set maxReceivedMessageSize in your binding. You can also need to set readerQuotas.

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding maxReceivedMessageSize="10485760">
        <readerQuotas ... />
      </binding>
    </basicHttpBinding>
  </bindings>  
</system.serviceModel>

Campanula

i have set the maxRecievedMessageSize to the above value but still I get the same error.. Request Entity is too large.. – Intrigante

@Sandepku- Just in case...I had this same problem for quite a long time, and then realized that I had misnamed the Binding Name, so WCF was using the default values instead of my config values, and was giving me the exact same error. – Goldeye

i have set the maxRecievedMessageSize to the above value but still I get the same error.. Request Entity is too large. Binding name is not empty. Help! – Tractarianism

Thank you Sir, this was helpful right away! Setting a new value for maxReceivedMessageSize requires the same value to be set for maxBufferSize. – Vitebsk

@Intrigante if you are using webhttpbinding for REST, then you may need to make binding name in <binding> equal to bindingConfiguration in <endpoint> – Kannry

Please edit answer, add name to binding: <binding name="FvsBasicHttp"... and then edit endpoint with that name: <endpoint binding="basicHttpBinding" bindingConfiguration="FvsBasicHttp" ...> – Lepine

@Ramunas: Why? Newer versions of WCF don't need named configurations - it becomes default setting. – Campanula

@Ladislav Mrnka: I have wcf (.net 4) project which runs as windows service, without binding name configuration is not used. Maybe it works well on ISS, have not checked. Also with names you can have more than one setting. – Lepine

I got it working using this answer without having to set readerQuotas – Astrophotography

@Tractarianism maxRecievedMessageSize is a misspelling. Did you spell the setting correctly? Should be maxReceivedMessageSize (e before i in "Received") – Toot

Answer 2

I was having the same issue with IIS 7.5 with a WCF REST Service. Trying to upload via POST any file above 65k and it would return Error 413 "Request Entity too large".

The first thing you need to understand is what kind of binding you've configured in the web.config. Here's a great article...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

If you have a REST service then you need to configure it as "webHttpBinding". Here's the fix:

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>

Disrespect

Thanks, this worked for me using IIS 7.5 with a WCF REST service. In fact, I only had to modify the maxReceivedMessageSize attribute. – Highclass

I had the maxReceivedMessageSize, the maxBufferSize did the trick, maxBufferPoolSize showed as an invalid attribute. – Emarginate

make sure you define binding name and make it equal to the bindingConfiguration on endpoint. Ex: <binding name="restLargeBinding" maxBufferPoolSize=..........>. And in service configuration; <endpoint address="" binding="webHttpBinding" bindingConfiguration="restLargeBinding"....... – Kannry

works great, although setting the transferMode="Streamed" gave me a bad request, had to remove that one – Lagan

@Kannry I know it's old, but the bindingConfiguration="restLargeBinding" did the trick for me! By the way I'm using self hosted wcf service. – Pigweed

Answer 3

I had the same problem and setting the uploadReadAheadSize solved it:

http://www.iis.net/configreference/system.webserver/serverruntime

"The value must be between 0 and 2147483647."

It is easily set it in the applicationHost.config-fle if you don't want to do a cmd-thing.

Its located in WindowsFOLDER\System32\inetsrv\config (2008 server).

You must open it with notepad. Do a Backup of the file first.

According to the comments in config the recommended way to unlock sections is by using a location tag:

<location path="Default Web Site" overrideMode="Allow">
    <system.webServer>
        <asp />
    </system.webServer>
</location>"

So you can write in the bottom (since it doesn't exist before). I write maxvalue here - write your own value if you want.

<location path="THENAMEOFTHESITEYOUHAVE" overrideMode="Allow">
    <system.webServer>
        <asp />
        <serverRuntime uploadReadAheadSize="2147483647" />
    </system.webServer>
</location>

If you put it last before </configuration> for example, you know where you have it.

Hope that solves your problems. It was an SSL overhead issue for me, where too much post freezed the application, raising a (413) Request Entity Too Large error.

Pull

Having already set maxReceivedMessageSize to int.MaxValue, this did the trick. I wonder if there are any major concerns with setting this option to int.MaxValue as well? – Obstipation

Would anyone know if uploadReadAheadSize is also relevant to self-hosted WCF services, not running via IIS? i.e. is this also an issue related to Windows Server in general? – Dalesman

@Dalesman I have a self hosted api and suffering the same problem - did you solve it with your self hosted service? – Chicalote

Answer 4

I was receiving this error message, even though I had the max settings set within the binding of my WCF service config file:

<basicHttpBinding>
        <binding name="NewBinding1"
                 receiveTimeout="01:00:00"
                 sendTimeout="01:00:00"
                 maxBufferSize="2000000000"
                 maxReceivedMessageSize="2000000000">

                 <readerQuotas maxDepth="2000000000"
                      maxStringContentLength="2000000000"
                      maxArrayLength="2000000000" 
                      maxBytesPerRead="2000000000" 
                      maxNameTableCharCount="2000000000" />
        </binding>
</basicHttpBinding>

It seemed as though these binding settings weren't being applied, thus the following error message:

IIS7 - (413) Request Entity Too Large when connecting to the service.

The Problem

I realised that the name="" attribute within the <service> tag of the web.config is not a free text field, as I thought it was. It is the fully qualified name of an implementation of a service contract as mentioned within this documentation page.

If that doesn't match, then the binding settings won't be applied!

<services>
  <!-- The namespace appears in the 'name' attribute -->
  <service name="Your.Namespace.ConcreteClassName">
    <endpoint address="http://localhost/YourService.svc"
      binding="basicHttpBinding" bindingConfiguration="NewBinding1"
      contract="Your.Namespace.IConcreteClassName" />
  </service>
</services>

I hope that saves someone some pain...

Sobersided

Thanks for adding this solution! Indirectly solved my problem in that my contract name changed in dev but the change wasn't deployed to production properly. Checking these setting resolved my (413) Request Entity Too Large errors due to using default message size settings. – Ule

I'm really glad that this helped someone. I spent a good while on this so I hoped it would make someone's day less painful. – Sobersided

Isn't there a way to make the binding the defaults though so you don't need to setup endpoint and service contracts to line up in config? If the name isn't specified at all? – Toot

Answer 5

If you're running into this issue despite trying all of the solutions in this thread, and you're connecting to the service via SSL (e.g. https), this might help:

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

To summarize (in case the link dies in the future), if your requests are large enough the certificate negotiation between the client and the service will fail randomly. To keep this from happening, you'll need to enable a certain setting on your SSL bindings. From your IIS server, here are the steps you'll need to take:

1. Via cmd or powershell, run netsh http show sslcert. This will give you your current configuration. You'll want to save this somehow so you can reference it again later.
2. You should notice that "Negotiate Client Certificate" is disabled. This is the problem setting; the following steps will demonstrate how to enable it.
3. Unfortunately there is no way to change existing bindings; you'll have to delete it and re-add it. Run netsh http delete sslcert <ipaddress>:<port> where <ipaddress>:<port> is the IP:port shown in the configuration you saved earlier.
4. Now you can re-add the binding. You can view the valid parameters for netsh http add sslcert here (MSDN) but in most cases your command will look like this:

netsh http add sslcert ipport=<ipaddress>:<port> appid=<application ID from saved config including the {}> certhash=<certificate hash from saved config> certstorename=<certificate store name from saved config> clientcertnegotiation=enable

If you have multiple SSL bindings, you'll repeat the process for each of them. Hopefully this helps save someone else the hours and hours of headache this issue caused me.

EDIT: In my experience, you can't actually run the netsh http add sslcert command from the command line directly. You'll need to enter the netsh prompt first by typing netsh and then issue your command like http add sslcert ipport=... in order for it to work.

Outtalk

Thank you for the post, it helped isolate the issue for us, turning off SSL removes the WCF error. Unfortunately the clientcertnegotiation didn't change our outcome to work over SSL. Stil looking for other bits to toggle :-( – Lonlona

Answer 6

This helped me to resolve the problem (one line - split for readability / copy-ability):

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost

Ulphiah

are you hosting your WCF in the SharePoint environment? and did you have to restart your IIS after applying the changes? – Censor

Answer 7

For me, setting the uploadReadAheadSize to int.MaxValue also fixed the problem, after also increasing the limits on the WCF binding.

It seems that, when using SSL, the entire request entity body is preloaded, for which this metabase property is used.

For more info, see:

The page was not displayed because the request entity is too large. iis7

Unipersonal

Your finding about SSL and 'uploadReadAheadSize' is very good! .. But I do not recommend to set it to max value though – Guyon

Answer 8

In my case, I was getting this error message because I was changed the service's namespace and services tag was pointed to the older namespace. I refreshed the namespace and the error disapear:

<services>
  <service name="My.Namespace.ServiceName"> <!-- Updated name -->
    <endpoint address="" 
              binding="wsHttpBinding" 
              bindingConfiguration="MyBindingConfiguratioName" 
              contract="My.Namespace.Interface" <!-- Updated contract -->
    />
  </service>
</services>

Hushhush

Answer 9

My problem has gone after I added this:

  <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits
                    maxAllowedContentLength="104857600"
                />
            </requestFiltering>
        </security>
  </system.webServer>

Media

Answer 10

For anyone else ever looking for an IIS WCF error 413 : Request entity to large and using a WCF service in Sharepoint, this is the information for you. The settings in the application host and web.config suggested in other sites/posts don't work in SharePoint if using the MultipleBaseAddressBasicHttpBindingServiceHostFactory. You can use SP Powershell to get the SPWebService.Content service, create a new SPWcvSettings object and update the settings as above for your service (they won't exist). Remember to just use the name of the service (e.g. [yourservice.svc]) when creating and adding the settings. See this site for more info https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

Open

Answer 11

In my case I had to increase the "Maximum received message size" of the Receive Location in BizTalk. That also has a default value of 64K and so every message was bounced by BizTAlk regardless of what I configured in my web.config

Standoffish

Answer 12

I've been able to solve this by executing a dummy call ( e.g. IsAlive returning true ) just before the request with large content on the same wcf channel/client. Apparently ssl negotation is done on the first call. So no need to increase Uploadreadaheadsize.

Grower

Answer 13

Got a similar error on IIS Express with Visual Studio 2017.

HTTP Error 413.0 - Request Entity Too Large

The page was not displayed because the request entity is too large.

Most likely causes:

• The Web server is refusing to service the request because the request entity is too large.

• The Web server cannot service the request because it is trying to negotiate a client certificate but the request entity is too large.

• The request URL or the physical mapping to the URL (i.e., the physical file system path to the URL's content) is too long.

Things you can try:

• Verify that the request is valid.

• If using client certificates, try:

  • Increasing system.webServer/serverRuntime@uploadReadAheadSize

  • Configure your SSL endpoint to negotiate client certificates as part of the initial SSL handshake. (netsh http add sslcert ... clientcertnegotiation=enable) .vs\config\applicationhost.config

Solve this by editing \.vs\config\applicationhost.config. Switch serverRuntime from Deny to Allow like this:

<section name="serverRuntime" overrideModeDefault="Allow" />

If this value is not edited, you will get an error like this when setting uploadReadAheadSize:

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

Then edit Web.config with the following values:

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...

Adulterer

If you vote down, please say why. Very hard to improve answers otherwise. – Adulterer

Answer 14

for issue the remote server returned an unexpected response: (413) Request Entity Too Large on WCF with Resful

please see my explain configuration

</client>
<serviceHostingEnvironment multipleSiteBindingsEnabled="false" aspNetCompatibilityEnabled="true"/>

<bindings>

   <!-- this for restfull service -->
  <webHttpBinding>
    <binding name="RestfullwebHttpBinding"
      maxBufferPoolSize="2147483647"
      maxReceivedMessageSize="2147483647"
      maxBufferSize="2147483647" transferMode="Streamed">

      <readerQuotas 
        maxDepth="2147483647" 
        maxStringContentLength="2147483647"
        maxArrayLength="2147483647" 
        maxBytesPerRead="2147483647" /> 

    </binding>
  </webHttpBinding>
  <!-- end -->

   <!-- this for Soap v.2 -->
  <wsHttpBinding>
    <binding name="wsBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
      <!--UsernameToken over Transport Security-->
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName" establishSecurityContext="true"/>
      </security>
    </binding>
  </wsHttpBinding>
   <!-- this for restfull service -->

   <!-- this for Soap v.1 -->
  <basicHttpBinding>
    <binding name="basicBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false" transferMode="Streamed">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <security mode="None"/>
    </binding>
  </basicHttpBinding>
</bindings> 
<!-- end -->

<services>
  <clear/>

  <service name="ING.IWCFService.CitisecHashTransfer"  >
    <endpoint address="http://localhost:8099/CitisecHashTransfer.svc"
                  behaviorConfiguration="RestfullEndpointBehavior"
                  binding="webHttpBinding"
                  bindingConfiguration="RestfullwebHttpBinding"
                  name="ICitisecHashTransferBasicHttpBinding"
                  contract="ING.IWCFService.ICitisecHashTransfer" />
  </service>

</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <serviceMetadata httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>

      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="ING.IWCFService.IWCFServiceValidator, ING.IWCFService"/>
      </serviceCredentials>
      <serviceSecurityAudit auditLogLocation="Application" serviceAuthorizationAuditLevel="SuccessOrFailure" messageAuthenticationAuditLevel="SuccessOrFailure"/>
      <serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="100" maxConcurrentInstances="1000"/>

    </behavior>
    <behavior>
      <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
    </behavior>
  </serviceBehaviors>
  <endpointBehaviors>
    <behavior name="EndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647" />
    </behavior> 
    <behavior name="RestfullEndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647"  />
      <webHttp/>
    </behavior> 
  </endpointBehaviors>
</behaviors>

Ctenophore

Answer 15

Glued a lot of responses together will ALL info I needed:

IIS Config: C:\Windows\System32\inetsrv\config\applicationHost.config (very bottom)

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
...
<location path="Default Web Site">
        <system.webServer>
            <security>
                <access sslFlags="SslNegotiateCert" />
                <!-- Max upload size in bytes -->
                <requestFiltering>
                     <requestLimits maxAllowedContentLength="104857600" />
                </requestFiltering>
            </security>
        </system.webServer>
    </location>
</configuration>

Shupe

Answer 16

I want to share my experience in case anyone has the same issue.

Having the (413) Request Entity Too Large message, I tried all the responses above. At the end, the upload limit was increased but I was still having the same message for some files randomly.

Here is my web config file content:

 <services>
   //Corresponds to my service name, if there is a namespace, it must be indicated. like MyNameSpace.MyWcfService.
    <service name="MyWcfService">
        <endpoint
        binding="basicHttpsBinding" //For https configuration. Can be http according to the situation.
        name="cadelioDefaultConfig"
        bindingConfiguration="myAppMaxTransportBinding" //The exact name of the binding configuration defined below.
        contract="IService" />
        
            <endpoint address="mex"
            binding="mexHttpsBinding" 
            contract="IMetadataExchange" />
    
    </service>
</services>

<behaviors>
    <serviceBehaviors>
        <behavior>
            <serviceMetadata 
            httpGetEnabled="true" 
            httpsGetEnabled="true" />
            <serviceDebug includeExceptionDetailInFaults="true" />
            <useRequestHeadersForMetadataAddress />
        </behavior>
    </serviceBehaviors>
</behaviors>

<protocolMapping>
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />

<bindings>
    <basicHttpsBinding> //Https binding, can be http accordin to the situation.
        <binding 
        name="myAppMaxTransportBinding" 
        closeTimeout="00:10:00"
        openTimeout="00:10:00"
        receiveTimeout="01:00:00" 
        sendTimeout="01:00:00" 
        maxBufferPoolSize="2147483647"
        maxBufferSize="2147483647"
        maxReceivedMessageSize="2147483647"
        transferMode="Streamed">

            <readerQuotas maxStringContentLength="2147483647"
            maxArrayLength="2147483647" 
            maxBytesPerRead="2147483647" 
            maxDepth="2147483647" 
            maxNameTableCharCount="2147483647" />

        </binding>
    </basicHttpsBinding>
</bindings>
   

Still the same message at the end but not always.

I realised that when the file was larger than 30 MB, I was still getting this error after all I tried in my webconfig file.

Finally, I found that in IIS, in the Request filtering section, there is an upload limit by default 30000000 bytes.

I opened the Request filtering page, edited the Feature Settings and put the limit I need.

And bingo.

Cloison

Answer 17

Just in case anyone has an Application Request router in front of their application make sure that you are adjusting the settings for and there as well.

Altamira

You are going to need to share some sample code and add some more explanation – Aplasia