Ошибка 413 request entity too large iis

asked Apr 12, 2012 at 11:49

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>

answered Apr 12, 2012 at 12:39

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>

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 WindowsFOLDERSystem32inetsrvconfig (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.

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…

answered Mar 22, 2016 at 16:19

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.

answered Mar 29, 2016 at 19:04

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

C:WindowsSystem32inetsrvappcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost

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

answered Oct 24, 2017 at 13:32

Vladimir VenegasVladimir Venegas

3,5545 gold badges25 silver badges45 bronze badges

reknarekna

5,2817 gold badges44 silver badges54 bronze badges

Liam KernighanLiam Kernighan

2,2471 gold badge21 silver badges23 bronze badges

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) .vsconfigapplicationhost.config

Solve this by editing .vsconfigapplicationhost.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" />
...

answered Feb 25, 2019 at 18:49

KevinKevin

2,22819 silver badges22 bronze badges

Другие языки:

How to fix Error 413 (Request Entity Too Long) — The requested file was too large to process.
Wie beheben Fehler 413 (Anfrage Entität zu lang) — Die angeforderte Datei war zu groß für die Verarbeitung.
Come fissare Errore 413 (Richiesta Entità Troppo Long) — Il file richiesto era troppo grande per essere elaborato.
Hoe maak je Fout 413 (Verzoek Entiteit Te lang) — Het gevraagde bestand was te groot om te verwerken.
Comment réparer Erreur 413 (Entité de la demande trop longue) — Le fichier demandé était trop volumineux pour être traité.
어떻게 고치는 지 오류 413 (요청 항목이 너무 깁니다.) — 요청한 파일이 너무 커서 처리할 수 없습니다.
Como corrigir o Erro 413 (Solicitar Entidade Muito Longa) — O arquivo solicitado era muito grande para ser processado.
Hur man åtgärdar Fel 413 (Begäran Entitet för lång) — Den begärda filen var för stor för att behandlas.
Jak naprawić Błąd 413 (Żądanie Jednostki Zbyt długie) — Żądany plik był za duży do przetworzenia.
Cómo arreglar Error 413 (Solicitar entidad demasiado larga) — El archivo solicitado era demasiado grande para procesarlo.

Об авторе: Фил Харт является участником сообщества Microsoft с 2010 года. С текущим количеством баллов более 100 000 он внес более 3000 ответов на форумах Microsoft Support и создал почти 200 новых справочных статей в Technet Wiki.