Solution for “Request Entity Too Large” error
Published Apr 29 2019 02:33 PM 308K Views
Microsoft

IIS has a limit for the size of the files users can upload to an application. If the file size exceeds the limit, the application will throw “Error in HTTP request, received HTTP status 413 (Request Entity Too Large)” error.

 

The default file upload size is 49 KB (49152 bytes). The application records the log below if user tries to upload a file that is bigger than this size.

 

3.jpg

 

Why this issue occurs for SSL sites? The reason is that the request body must be preloaded during the SSL handshake process.

 

Solution

The quickest solution is to increase the upload size limit. IIS uses uploadReadAheadSize parameter in applicationHost.config and web.config files to control this limit.

 

uploadReadAheadSize
Optional uint attribute.
Specifies the number of bytes that a Web server will read into a buffer and pass to an ISAPI extension or module. This occurs once per client request. The ISAPI extension or module receives any additional data directly from the client. The value must be between 0 and 2147483647.
The default value is 49152.

Server Runtime

 

Steps to change the value of this parameter:

  1. Open IIS Manager
  2. Select the site
  3. Double click “Configuration Editor”
  4. Select system.webServer and then serverRuntime
  5. Modify the uploadReadAheadSize value
  6. Click “Apply”

 

4.jpg

 

You may also want to change maxRequestEntityAllowed parameter. It specifies the maximum number of bytes allowed in the request body.

 

Note: In another case, the recommendations above didn't work to solve 413 error. Please check this post for more information

13 Comments
Copper Contributor

Did the above and I'm still seeing 413 responses from my server:(

Trying to post back a RadSpreadheet over 50KB on an SSL connection...

I set the uploadReadAheadSize to 100MB, the actual file is around 100KB so you wiuld think it would be fine right... rebooted the server just to be sure...

No impact!

Microsoft

@JWANicholls2807 Thanks for checking out the post! Can you please check what the substatus code in IIS logs? Additionally, please set up Failed Tracing Logs to see which module is throwing the error

Copper Contributor

Hi I'm also encountering this in our On-premise instance of DevOps and this is the first time we are encountering such issues.  In our previous version of TFS 2017 this was never an issue. Was there a big change in DevOps 2019 using SSL?

Microsoft

Hi @RayCuadra71 I would appreciate if you post this question to our DevOps Community: https://developercommunity.visualstudio.com/spaces/22/index.html

Copper Contributor

Hi,

Thank you for the post. But, we still see the error. Please read below for what all we had tried. Please let us know if there is anything missing or that we should try. APpreciate your help.

 

We made WCF web service using SOAP (factory: MultipleBaseAddressBasicHttpBindingServiceHostFactory) hosted in SharePoint environment (under ISAPI folder)

We are able to upload larger files (larger than 49KB) in the SP2010 farms but receive "remote server returned an unexpected response: (413) Request Entity Too Large" error after upgrading to SP2013 environment.

 

After reading some posts, still received the same error message: "remote server returned an unexpected response: (413) Request Entity Too Large".

 

We wonder if anyone might have any sugegstions to resolve the issue. Thanks in advance!

 

Changes made are:

(1) in IIS, check IIS Request Filtering features setting for the WCF service > ensure "Maximum Allowed Content Length" is large enough

(2) in IIS, increase UploadReadAheadSize value from 49152 to 52428800 (even to maximal value: 2147483647)

(3) in SP2013 CA > Application Management > Manage web application > select <webapp> > click "General Setting" in the ribbon > ensure "File Upload Size" is large enough

(4) update binding & enpoint in web service's web.config, e.g.

 

<bindings>

      <basicHttpBinding>

        <binding maxBufferPoolSize="2147483647"

                  maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" transferMode="Streamed">

          <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"

                maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />

          <security mode="TransportCredentialOnly">

            <transport clientCredentialType="Ntlm" />

          </security>

        </binding>

      </basicHttpBinding>

</bindings>

 

<services>

                <service name="<namespace>.<servicename>" behaviorConfiguration="<namespace>.<servicename>Behavior">

                                <endpoint address="basic" binding="basicHttpBinding" contract="<namespace>.<serviceinterfacename>">

                                </endpoint>

 

                </service>

</services>

 

(5) update app.config in application console client, e.g.

 

                <binding name="BasicHttpBinding_<serviceinterfacename>" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

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

                    <security mode="TransportCredentialOnly">

                        <transport clientCredentialType="Ntlm" />

                    </security>

                </binding>

 

Microsoft

Hi @Udi123, it looks like you have already implemented the recommended solutions. Since you run into this issue in SharePoint, I think it's a good case for collaboration between SharePoint and IIS Teams. Can you please create a support request for further troubleshooting?

 

https://support.microsoft.com/en-ca/hub/4343728/support-for-business

Copper Contributor

Hi All ,

 

i have done the above recommendation but nothing wroks ! 

 any solution ?

Copper Contributor

For MVC add [RequestSizeLimit(50_000_000)] annotation to the specific action or controller.

 

Setup the maxAllowedContentLength parameter in the system->webServer->security->requestFiltering section:

 

Capture.PNG

Copper Contributor

@Udi123 , Hi!
I was helped by the change from point (4) of your post.


(4) update binding & enpoint in web service's web.config, e.g.

 

<bindings>

      <basicHttpBinding>

        <binding maxBufferPoolSize="2147483647"

                  maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" transferMode="Streamed">

          <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"

                maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />

          <security mode="TransportCredentialOnly">

            <transport clientCredentialType="Ntlm" />

          </security>

        </binding>

      </basicHttpBinding>

</bindings>

 

Copper Contributor

In terms of performance, the above suggestion actually has the potential to significantly increase your memory consumption and negatively impact your application.

I came across the exact same issue early this year, and initially thought that your suggestion above would be an obvious way to solve it.

Unfortunately, further reading revealed the knock on effects of ramping up the sizes as suggested.

 

The answer came partially from this post:

https://forums.iis.net/t/1161838.aspx

Basically, what you need to do is force the server to negotiate the client certificate *before* it does anything else, and that way your server won't complain about being unable to buffer the request body as it will already have done the negotiation.

 

Here's the steps to follow

1) Open a command prompt

2) Run netsh http show sslcert
3) Note down the Certificate Hash and Application ID values for Your app (typically running on port 443 or similar)
4) Delete the existing certificate binding for port 443 (or whichever port you're using)

netsh http delete sslcert ipport=0.0.0.0:443


5) Re-create the port binding using the same certificate hash and application id that you noted in step 3 ensuring the appid is enclosed in braces as shown in the example below

Caution - below is an example - you need to substitute the certhash and appid before executing

netsh http add sslcert ipport=0.0.0.0:443 certhash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx appid={xxxxx-xxxxx-xxxx-xxxx-xxxxxx} certstorename=WebHosting verifyclientcertrevocation=enable VerifyRevocationWithCachedClientCertOnly=disable UsageCheck=Enable clientcertnegotiation=enable


6) Run netsh http show sslcert
7) Validate that the Negotiate Client Certificate setting for the port is now enabled.

 

You should then find you can submit your request without having to do anything else at all :)

Copper Contributor

There are lots of solutions/comments here, none of which address the fundamental question.  What entity is too large?   We had the same issue and we eventually identified that the entity in error was a viewstate object in the ASPX page.   Just making the size of the maxBufferPoolSize,  maxBufferSize and maxReceivedMessageSize to be enormously large is not really the correct solution.  It will work but you're only masking the problem and it'll occur at some point in the future.


ViewState
A web application is stateless. That means that a new instance of a page is created every time when we make a request to the server to get the page and after the round trip our page has been lost immediately. It only happens because of one server, all the controls of the Web Page is created and after the round trip the server destroys all the instances. So to retain the values of the controls we use state management techniques. View State is the method to preserve the Value of the Page and Controls between round trips. It is a Page-Level State Management technique. View State is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a post-back.

Solution
Our webpage was displaying a gridview of records which by user request gave access to every record in the underlying data query view.  As records were added to the tables outside of this view, the Gridview Dataset grew to be too large for the ASPX page to save and recall the viewstate object.  Our solution was to understand the business reasons why the whole of the dataset was required and as it turned out generally it was only the last 7 days worth of data that was required, any further back in time was catered for by a standing report.  Once this was understood then we simply amended the page query to limit to the last 7 days of data, promulgate the change and inform users.  Problem fixed.  

Copper Contributor

@KevinP_SBS I disagree; your message is specific to viewstate, mine was in a Web API app which means viewstate is irrelevant; we knew what size we wanted to limit for requests, and if you read my post, nor have I advocated setting huge buffer sizes.

My solution allows people to set a fixed size for an API request submission, and hence addresses the issue.  Similarly, the original poster was asking about file uploads - something which your workaround also doesn't address.  Let's keep it civil please, everyone has contributed helpful posts.

Copper Contributor

Thanks!

Co-Authors
Version history
Last update:
‎May 25 2021 01:33 PM
Updated by: