(413) Zbyt duża jednostka żądania | uploadReadAheadSize

Napisałem usługę WCF z .NET 4.0, która jest hostowana na moim systemie Windows 7 x64Ultimate z IIS 7.5. Jedna z metod usługi ma „obiekt” jako argument i próbuję wysłać bajt [], który zawiera obraz. O ile rozmiar pliku tego obrazu jest mniejszy niż ok. 48 KB, wszystko idzie dobrze. Ale jeśli próbuję przesłać większy obraz, usługa WCF zwraca błąd: (413) Request Entity Too Large. Oczywiście spędziłem 3 godziny na wyszukiwaniu w Google komunikatu o błędzie, a każdy temat, który widziałem na ten temat, sugeruje podniesienie właściwości „uploadReadAheadSize”. Więc to, co zrobiłem, to użycie następujących poleceń (10485760 = 10 MB):

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

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

Użyłem również Menedżera IIS do ustawienia wartości, otwierając witrynę i przechodząc do „Edytora konfiguracji” w sekcji Zarządzanie. Niestety nadal otrzymuję błąd Zbyt duża jednostka żądania i robi się to naprawdę frustrujące!

Więc czy ktoś wie, co jeszcze mogę spróbować naprawić ten błąd?

To nie jest problem IIS, ale problem WCF. Usługa WCF domyślnie ogranicza komunikaty do 65 KB, aby uniknąć ataku typu „odmowa usługi” z dużymi komunikatami. Również jeśli nie używasz MTOM, wysyła bajt [] do łańcucha zakodowanego algorytmem base64 (wzrost rozmiaru o 33%) => 48KB * 1,33 = 64KB

Aby rozwiązać ten problem, musisz ponownie skonfigurować usługę, aby akceptowała większe wiadomości. Ten problem wcześniej wywołał błąd nieprawidłowego żądania 400, ale w nowszej wersji WCF zaczął używać 413, który jest poprawnym kodem stanu dla tego typu błędu.

Musisz ustawić maxReceivedMessageSizeswoje wiązanie. Możesz także ustawić readerQuotas.

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

Miałem ten sam problem z usługami IIS 7.5 z usługą WCF REST. Próba przesłania przez POST dowolnego pliku powyżej 65 KB i zwróci błąd 413 „Żądanie jednostki jest zbyt duże”.

Pierwszą rzeczą, którą musisz zrozumieć, jest rodzaj wiązania skonfigurowanego w pliku web.config. Oto świetny artykuł ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Jeśli masz usługę REST, musisz skonfigurować ją jako „webHttpBinding”. Oto poprawka:

<system.serviceModel>

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

Miałem ten sam problem i ustawiając uploadReadAheadSizego rozwiązałem:

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

„Wartość musi zawierać się w przedziale od 0 do 2147483647.”

Można to łatwo ustawić w pliku applicationHost.config-fle, jeśli nie chcesz wykonywać czynności cmd.

Znajduje się na WindowsFOLDER\System32\inetsrv\config(serwer 2008).

Musisz go otworzyć za pomocą notatnika. Najpierw wykonaj kopię zapasową pliku.

Zgodnie z komentarzami w config, zalecanym sposobem odblokowania sekcji jest użycie tagu lokalizacji:

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

Możesz więc pisać na dole (ponieważ wcześniej tego nie było). Piszę maxvaluetutaj - napisz swoją wartość, jeśli chcesz.

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

Jeśli </configuration>na przykład umieścisz go na końcu , wiesz, gdzie go masz.

Mam nadzieję, że to rozwiązuje twoje problemy. Był to dla mnie problem z narzutem SSL, gdzie zbyt duża liczba postów zawieszała aplikację, powodując błąd (413) Request Entity Too Large .

Otrzymałem ten komunikat o błędzie, mimo że maxustawienia zostały ustawione w ramach powiązania mojego pliku konfiguracyjnego usługi WCF:

<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>

Wyglądało na to, że te ustawienia powiązań nie zostały zastosowane, dlatego pojawił się następujący komunikat o błędzie:

IIS7 - (413) żądanie jednostki jest zbyt duże podczas łączenia się z usługą.

.

Problem

Zdałem sobie sprawę, że name=""atrybut w <service>tagu z web.configto nie darmowy pole tekstowe, jak myślałem, że to. Jest to w pełni kwalifikowana nazwa realizacji umowy serwisowej, jak wspomniano na tej stronie dokumentacji .

Jeśli to nie pasuje, ustawienia powiązania nie zostaną zastosowane!

<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>

Mam nadzieję, że to komuś oszczędza trochę bólu ...

Jeśli napotykasz ten problem pomimo wypróbowania wszystkich rozwiązań w tym wątku i łączysz się z usługą przez SSL (np. Https), może to pomóc:

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

Podsumowując (w przypadku, gdy łącze znika w przyszłości), jeśli Twoje żądania są wystarczająco duże, negocjacja certyfikatu między klientem a usługą zakończy się losowo. Aby temu zapobiec, musisz włączyć określone ustawienie w powiązaniach SSL. Oto kroki, które musisz wykonać na serwerze IIS:

1. Za pomocą cmd lub powershell uruchom netsh http show sslcert . Dzięki temu uzyskasz aktualną konfigurację. Będziesz chciał to jakoś zapisać, aby móc później odwołać się do niego.
2. Należy zauważyć, że opcja „Negotiate Client Certificate” jest wyłączona. To jest ustawienie problemu; poniższe kroki pokażą, jak to włączyć.
3. Niestety nie ma możliwości zmiany istniejących powiązań; będziesz musiał go usunąć i ponownie dodać. Biegnij netsh http delete sslcert <ipaddress>:<port>gdzie<ipaddress>:<port> jest IP: port pokazany w zapisanej wcześniej konfiguracji.
4. Teraz możesz ponownie dodać wiązanie. Możesz wyświetlić prawidłowe parametry netsh http add sslcert tutaj (MSDN), ale w większości przypadków polecenie będzie wyglądać następująco:

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

Jeśli masz wiele powiązań SSL, powtórz proces dla każdego z nich. Mam nadzieję, że pomoże to komuś zaoszczędzić wiele godzin bólu głowy, który spowodował ten problem.

EDYCJA: Z mojego doświadczenia wynika, że ​​nie można w rzeczywistości uruchomić netsh http add sslcertpolecenia bezpośrednio z wiersza poleceń. Najpierw musisz wpisać znak zachęty netsh, wpisując, netsha następnie wydając polecenie http add sslcert ipport=..., aby zadziałało.

To pomogło mi rozwiązać problem (jedna linia - podzielona ze względu na czytelność / możliwość kopiowania):

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

Dla mnie ustawienie uploadReadAheadSizeint.MaxValue również rozwiązało problem, po zwiększeniu limitów powiązania WCF.

Wygląda na to, że przy korzystaniu z SSL cała treść jednostki żądania jest wstępnie ładowana, dla której ta właściwość metabazy jest używana.

Aby uzyskać więcej informacji, zobacz:

Strona nie została wyświetlona, ​​ponieważ jednostka żądania jest za duża. iis7

Dla każdego, kto kiedykolwiek szukał błędu 413 programu IIS WCF: Zażądaj jednostki do dużej i korzystającej z usługi WCF w programie Sharepoint, to są informacje dla Ciebie. Ustawienia w hoście aplikacji i web.config sugerowane w innych witrynach / postach nie działają w programie SharePoint, jeśli używasz właściwości MultipleBaseAddressBasicHttpBindingServiceHostFactory. Możesz użyć SP Powershell, aby uzyskać usługę SPWebService.Content, utworzyć nowy obiekt SPWcvSettings i zaktualizować ustawienia jak wyżej dla swojej usługi (nie będą istnieć). Pamiętaj, aby podczas tworzenia i dodawania ustawień używać tylko nazwy usługi (np. [Yourservice.svc]). Zobacz tę witrynę, aby uzyskać więcej informacji https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

W moim przypadku musiałem zwiększyć „Maksymalny rozmiar odebranej wiadomości” w lokalizacji odbioru w BizTalk. Ma to również domyślną wartość 64 KB, więc każda wiadomość została odesłana przez BizTAlk niezależnie od tego, co skonfigurowałem w moim web.config

Udało mi się to rozwiązać, wykonując fikcyjne wywołanie (np. IsAlive zwracające true) tuż przed żądaniem z dużą zawartością na tym samym kanale / kliencie WCF. Najwyraźniej negocjacja SSL odbywa się przy pierwszym wywołaniu. Więc nie ma potrzeby zwiększania Uploadreadaheadsize.

w przypadku problemu serwer zdalny zwrócił nieoczekiwaną odpowiedź: (413) żądanie jednostki zbyt dużej na WCF z Resful

zobacz moją konfigurację wyjaśniającą

</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>

W moim przypadku otrzymywałem ten komunikat o błędzie, ponieważ zmieniono przestrzeń nazw usługi, a tag usług został wskazany na starszą przestrzeń nazw. Odświeżyłem przestrzeń nazw i błąd zniknął:

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

Wystąpił podobny błąd w usługach IIS Express z programem Visual Studio 2017.

Błąd HTTP 413.0 - zbyt duża jednostka żądania

Strona nie została wyświetlona, ​​ponieważ jednostka żądania jest za duża.

Prawdopodobne przyczyny:

• Serwer sieci Web odmawia obsługi żądania, ponieważ jednostka żądania jest zbyt duża.

• Serwer sieci Web nie może obsłużyć żądania, ponieważ próbuje negocjować certyfikat klienta, ale jednostka żądania jest zbyt duża.

• Adres URL żądania lub fizyczne odwzorowanie na adres URL (tj. Fizyczna ścieżka systemu plików do zawartości adresu URL) jest za długa.

Możesz spróbować:

• Sprawdź, czy żądanie jest prawidłowe.

• Jeśli używasz certyfikatów klienta, spróbuj:

  • Zwiększenie system.webServer/serverRuntime@uploadReadAheadSize

  • Skonfiguruj punkt końcowy SSL do negocjowania certyfikatów klienta w ramach wstępnego uzgadniania SSL. (netsh http dodaj sslcert ... clientcertnegotiation = włącz) .vs \ config \ applicationhost.config

Rozwiąż ten problem, edytując \.vs\config\applicationhost.config. Przełącz się serverRuntimez Denyna w Allowten sposób:

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

Jeśli ta wartość nie jest edytowana, podczas ustawiania pojawi się taki błąd uploadReadAheadSize:

Błąd HTTP 500,19 - wewnętrzny błąd serwera

Nie można uzyskać dostępu do żądanej strony, ponieważ powiązane dane konfiguracyjne strony są nieprawidłowe.

Ta sekcja konfiguracji nie może być używana w tej ścieżce. Dzieje się tak, gdy sekcja jest zablokowana na poziomie rodzica. Blokowanie jest albo domyślnie (overrideModeDefault = "Deny"), albo ustawiane jawnie przez znacznik lokalizacji z overrideMode = "Deny" lub starszym allowOverride = "false".

Następnie edytuj, Web.configużywając następujących wartości:

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