Solution for “Request Entity Too Large” error

Thanks!

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.

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.  

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 🙂

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>

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:

Hi All ,

i have done the above recommendation but nothing wroks ! 

 any solution ?

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

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>

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