(413) Meminta Entitas Terlalu Besar | uploadReadAheadSize


140

Saya telah menulis layanan WCF dengan .NET 4.0, yang dihosting di sistem Windows 7 x64Ultimate saya dengan IIS 7.5. Salah satu metode layanan memiliki 'objek' sebagai argumen dan saya mencoba mengirim byte [] yang berisi gambar. Selama ukuran file gambar ini kurang dari kira-kira. 48KB, semuanya berjalan dengan baik. Tetapi jika saya mencoba mengunggah gambar yang lebih besar, layanan WCF mengembalikan kesalahan: (413) Request Entity Too Large. Jadi tentu saja saya telah menghabiskan 3 jam Googling pesan kesalahan dan setiap topik yang saya lihat tentang subjek ini menyarankan untuk menaikkan properti 'uploadReadAheadSize'. Jadi yang saya lakukan adalah menggunakan perintah berikut (10485760 = 10MB):

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

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

Saya juga telah menggunakan Manajer IIS untuk menetapkan nilai dengan membuka situs dan membuka "Editor Konfigurasi" di bawah Manajemen. Sayangnya, saya masih mendapatkan kesalahan Entitas Permintaan Terlalu Besar dan ini benar-benar membuat frustrasi!

Jadi apakah ada yang tahu apa lagi yang bisa saya coba untuk memperbaiki kesalahan ini?


6
10485760 = 10MB, bukan 1MB
Shaun Rowan

Jawaban:


211

Itu bukan masalah IIS tapi masalah WCF. WCF secara default membatasi pesan hingga 65 KB untuk menghindari serangan penolakan layanan dengan pesan besar. Juga jika Anda tidak menggunakan MTOM, ia mengirimkan byte [] ke string yang dikodekan base64 (peningkatan ukuran 33%) => 48KB * 1,33 = 64KB

Untuk mengatasi masalah ini, Anda harus mengkonfigurasi ulang layanan Anda untuk menerima pesan yang lebih besar. Masalah ini sebelumnya memicu kesalahan 400 Permintaan Buruk tetapi dalam versi yang lebih baru WCF mulai menggunakan 413 yang merupakan kode status yang benar untuk jenis kesalahan ini.

Anda perlu mengatur maxReceivedMessageSizepenjilidan Anda. Anda juga perlu mengatur readerQuotas.

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

9
saya telah menetapkan maxRecievedMessageSize ke nilai di atas tetapi saya masih mendapatkan kesalahan yang sama .. Entitas Permintaan terlalu besar ..
Sandepku

13
@ Sandepku- Untuk berjaga-jaga ... Saya mengalami masalah yang sama dalam waktu yang cukup lama, dan kemudian menyadari bahwa saya telah salah menamai Nama Binding, jadi WCF menggunakan nilai default alih-alih nilai konfigurasi saya, dan memberikan saya yang tepat kesalahan yang sama.
Adrian Carr

1
saya telah menetapkan maxRecievedMessageSize ke nilai di atas tetapi saya masih mendapatkan kesalahan yang sama .. Entitas Permintaan terlalu besar. Nama penjilidan tidak kosong. Tolong!
NetSide

2
Terima kasih Pak, ini sangat membantu! Menyetel nilai baru untuk maxReceivedMessageSize mengharuskan nilai yang sama disetel untuk maxBufferSize.
DiligentKarma

1
@Sandepku jika Anda menggunakan webhttpbinding untuk REST, maka Anda mungkin perlu membuat nama binding di <binding> sama dengan bindingConfiguration di <endpoint>
smoothumut

56

Saya mengalami masalah yang sama dengan IIS 7.5 dengan Layanan REST WCF. Mencoba mengunggah melalui POST file apa pun di atas 65k dan itu akan mengembalikan Kesalahan 413 "Permintaan Entitas terlalu besar".

Hal pertama yang perlu Anda pahami adalah jenis pengikatan yang telah Anda konfigurasikan di web.config. Ini artikel bagus ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Jika Anda memiliki layanan REST maka Anda perlu mengkonfigurasinya sebagai "webHttpBinding". Berikut perbaikannya:

<system.serviceModel>

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

2
Terima kasih, ini berfungsi untuk saya menggunakan IIS 7.5 dengan layanan REST WCF. Nyatanya, saya hanya perlu memodifikasi atribut maxReceivedMessageSize.
Alex Yuly

Saya memiliki maxReceivedMessageSize, maxBufferSize melakukan trik, maxBufferPoolSize ditampilkan sebagai atribut yang tidak valid.
JabberwockyDecompiler

4
pastikan Anda menentukan nama binding dan membuatnya sama dengan bindingConfiguration pada endpoint. Contoh: <binding name = "restLargeBinding" maxBufferPoolSize = ..........>. Dan dalam konfigurasi layanan; <endpoint address = "" binding = "webHttpBinding" bindingConfiguration = "restLargeBinding" .......
smoothumut

2
berfungsi dengan baik, meskipun pengaturan transferMode = "Streamed" memberi saya permintaan yang buruk, harus menghapusnya
WtFudgE

1
@smoothumut Saya tahu ini sudah tua, tetapi bindingConfiguration = "restLargeBinding" melakukan trik untuk saya! Omong-omong saya menggunakan layanan wcf yang dihosting sendiri.
ramires.cabral

27

Saya memiliki masalah yang sama dan mengatur uploadReadAheadSizepenyelesaiannya:

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

"Nilainya harus antara 0 dan 2147483647."

Ini dengan mudah diatur di applicationHost.config-fle jika Anda tidak ingin melakukan cmd-thing.

Itu terletak di WindowsFOLDER\System32\inetsrv\config(server 2008).

Anda harus membukanya dengan notepad. Lakukan backup file terlebih dahulu.

Menurut komentar di konfigurasi, cara yang disarankan untuk membuka kunci bagian adalah dengan menggunakan tag lokasi:

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

Jadi Anda bisa menulis di bawah (karena tidak ada sebelumnya). Saya menulis di maxvaluesini - tulis nilai Anda sendiri jika Anda mau.

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

</configuration>Misalnya, jika Anda meletakkannya terakhir sebelumnya , Anda tahu di mana Anda memilikinya.

Harapan itu menyelesaikan masalah Anda. Itu adalah masalah overhead SSL bagi saya, di mana terlalu banyak posting membekukan aplikasi, menimbulkan kesalahan (413) Permintaan Entitas Terlalu Besar .


1
Setelah diatur maxReceivedMessageSizeke int.MaxValue, ini berhasil. Saya ingin tahu apakah ada masalah besar dengan pengaturan opsi ini ke int.MaxValue juga?
Langdon

2
Adakah yang tahu jika uploadReadAheadSize juga relevan dengan layanan WCF yang dihosting sendiri, tidak berjalan melalui IIS? yaitu apakah ini juga masalah yang terkait dengan Windows Server secara umum?
antscode

@antscode Saya memiliki api yang dihosting sendiri dan mengalami masalah yang sama - apakah Anda menyelesaikannya dengan layanan yang dihosting sendiri?
Trevor Daniel

18

Saya menerima pesan kesalahan ini, meskipun saya telah maxmenyetel pengaturan dalam pengikatan file konfigurasi layanan WCF saya:

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

Sepertinya pengaturan pengikatan ini tidak diterapkan, oleh karena itu muncul pesan kesalahan berikut:

IIS7 - (413) Meminta Entitas Terlalu Besar saat menyambung ke layanan.

.

Masalah

Saya menyadari bahwa name=""atribut dalam <service>tag dari web.configini tidak kolom teks bebas, seperti yang saya pikir itu. Ini adalah nama yang sepenuhnya memenuhi syarat dari implementasi kontrak layanan seperti yang disebutkan dalam halaman dokumentasi ini .

Jika tidak cocok, maka pengaturan penjilidan tidak akan diterapkan!

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

Saya berharap itu menyelamatkan seseorang dari rasa sakit ...


1
Terima kasih telah menambahkan solusi ini! Secara tidak langsung memecahkan masalah saya karena nama kontrak saya berubah di dev tetapi perubahan itu tidak diterapkan ke produksi dengan benar. Memeriksa pengaturan ini menyelesaikan kesalahan (413) Permintaan Entitas Terlalu Besar saya karena menggunakan pengaturan ukuran pesan default.
Doug Knudsen

Saya sangat senang ini membantu seseorang. Aku menghabiskan banyak waktu untuk ini jadi aku berharap itu akan membuat hari seseorang tidak terlalu menyakitkan.
Lukas

9

Jika Anda mengalami masalah ini meskipun telah mencoba semua solusi di utas ini, dan Anda tersambung ke layanan melalui SSL (mis. Https), ini mungkin membantu:

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

Untuk meringkas (jika tautan mati di masa mendatang), jika permintaan Anda cukup besar, negosiasi sertifikat antara klien dan layanan akan gagal secara acak. Untuk mencegah hal ini terjadi, Anda harus mengaktifkan pengaturan tertentu pada pengikatan SSL Anda. Dari server IIS Anda, berikut adalah langkah-langkah yang perlu Anda lakukan:

  1. Melalui cmd atau PowerShell, jalankan netsh http show sslcert. Ini akan memberi Anda konfigurasi Anda saat ini. Anda pasti ingin menyimpannya, jadi Anda bisa mereferensikannya lagi nanti.
  2. Anda akan melihat bahwa "Negosiasikan Sertifikat Klien" dinonaktifkan. Ini adalah pengaturan masalah; langkah-langkah berikut akan menunjukkan cara mengaktifkannya.
  3. Sayangnya, tidak ada cara untuk mengubah binding yang ada; Anda harus menghapusnya dan menambahkannya kembali. Jalankan di netsh http delete sslcert <ipaddress>:<port>mana <ipaddress>:<port>IP: port ditampilkan dalam konfigurasi yang Anda simpan sebelumnya.
  4. Sekarang Anda dapat menambahkan kembali penjilidan. Anda dapat melihat parameter yang valid untuk di netsh http add sslcert sini (MSDN) tetapi dalam banyak kasus perintah Anda akan terlihat seperti ini:

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

Jika Anda memiliki beberapa pengikatan SSL, Anda akan mengulangi proses untuk masing-masing pengikatan. Semoga ini membantu menyelamatkan orang lain berjam-jam sakit kepala karena masalah ini menyebabkan saya.

EDIT: Dalam pengalaman saya, Anda tidak dapat benar-benar menjalankan netsh http add sslcertperintah dari baris perintah secara langsung. Anda harus memasukkan prompt netsh terlebih dahulu dengan mengetik netshdan kemudian mengeluarkan perintah Anda seperti http add sslcert ipport=...agar bisa berfungsi.


Terima kasih atas kirimannya, ini membantu mengisolasi masalah bagi kami, mematikan SSL akan menghapus kesalahan WCF. Sayangnya negosiasi klien tidak mengubah hasil kami untuk bekerja melalui SSL. Masih mencari bit lain untuk beralih :-(
Jafin

8

Ini membantu saya menyelesaikan masalah (satu baris - pisahkan untuk keterbacaan / kemampuan menyalin):

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

apakah Anda menghosting WCF Anda di lingkungan SharePoint? dan apakah Anda harus me-restart IIS Anda setelah menerapkan perubahan?
theITvideos

2

Bagi saya, menyetel uploadReadAheadSizeke int.MaxValue juga memperbaiki masalah, setelah juga meningkatkan batas pengikatan WCF.

Tampaknya, saat menggunakan SSL, seluruh badan entitas permintaan telah dimuat sebelumnya, di mana properti metabase ini digunakan.

Untuk info lebih lanjut, lihat:

Halaman tidak ditampilkan karena entitas permintaan terlalu besar. iis7


1
Temuan Anda tentang SSL dan 'uploadReadAheadSize' sangat bagus! .. Tapi saya tidak menyarankan untuk menyetelnya ke nilai maksimal sekalipun
Pelajar

1

Untuk orang lain yang pernah mencari kesalahan IIS WCF 413: Minta entitas ke besar dan menggunakan layanan WCF di Sharepoint, ini adalah informasi untuk Anda. Pengaturan di host aplikasi dan web.config yang disarankan di situs / postingan lain tidak berfungsi di SharePoint jika menggunakan MultipleBaseAddressBasicHttpBindingServiceHostFactory. Anda dapat menggunakan SP Powershell untuk mendapatkan layanan SPWebService.Content, membuat objek SPWcvSettings baru dan memperbarui pengaturan seperti di atas untuk layanan Anda (mereka tidak akan ada). Ingatlah untuk hanya menggunakan nama layanan (misalnya [layanananda.svc]) saat membuat dan menambahkan pengaturan. Lihat situs ini untuk info lebih lanjut https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service


1

Dalam kasus saya, saya harus meningkatkan "Ukuran pesan yang diterima maksimum" dari Lokasi Terima di BizTalk. Itu juga memiliki nilai default 64K dan setiap pesan dipantulkan oleh BizTAlk terlepas dari apa yang saya konfigurasikan di web.config saya


1

Saya bisa menyelesaikan ini dengan menjalankan panggilan palsu (misalnya IsAlive mengembalikan true) tepat sebelum permintaan dengan konten besar di saluran / klien wcf yang sama. Rupanya negotasi ssl dilakukan pada panggilan pertama. Jadi tidak perlu menambah Uploadreadaheadsize.


0

untuk masalah server jauh mengembalikan respons yang tidak terduga: (413) Permintaan Entitas Terlalu Besar di WCF dengan Resful

silakan lihat konfigurasi saya menjelaskan

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


0

Dalam kasus saya, saya mendapatkan pesan kesalahan ini karena saya telah mengubah namespace layanan dan tag layanan diarahkan ke namespace lama. Saya menyegarkan namespace dan kesalahan hilang:

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

0

Mendapat kesalahan serupa di IIS Express dengan Visual Studio 2017.

Kesalahan HTTP 413.0 - Entitas Permintaan Terlalu Besar

Halaman tidak ditampilkan karena entitas permintaan terlalu besar.

Penyebab yang paling mungkin:

  • Server Web menolak untuk melayani permintaan karena entitas permintaan terlalu besar.

  • Server Web tidak dapat melayani permintaan karena mencoba menegosiasikan sertifikat klien tetapi entitas permintaan terlalu besar.

  • URL permintaan atau pemetaan fisik ke URL (yaitu, jalur sistem file fisik ke konten URL) terlalu panjang.

Hal yang bisa Anda coba:

  • Verifikasi bahwa permintaan tersebut valid.

  • Jika menggunakan sertifikat klien, coba:

    • Meningkatkan system.webServer/serverRuntime@uploadReadAheadSize

    • Konfigurasikan titik akhir SSL Anda untuk menegosiasikan sertifikat klien sebagai bagian dari handshake SSL awal. (netsh http tambahkan sslcert ... clientcertnegotiation = aktifkan) .vs \ config \ applicationhost.config

Selesaikan ini dengan mengedit \.vs\config\applicationhost.config. Alihkan serverRuntimedari Denymenjadi Allowseperti ini:

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

Jika nilai ini tidak diedit, Anda akan mendapatkan kesalahan seperti ini saat mengatur uploadReadAheadSize:

Kesalahan HTTP 500.19 - Kesalahan Server Internal

Halaman yang diminta tidak dapat diakses karena data konfigurasi terkait untuk halaman tersebut tidak valid.

Bagian konfigurasi ini tidak dapat digunakan di jalur ini. Ini terjadi ketika bagian tersebut dikunci di tingkat induk. Penguncian bisa dilakukan secara default (overrideModeDefault = "Deny"), atau diatur secara eksplisit oleh tag lokasi dengan overrideMode = "Deny" atau legacy allowOverride = "false".

Kemudian edit Web.configdengan nilai-nilai berikut:

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

Jika Anda menolak, sebutkan alasannya. Sangat sulit untuk memperbaiki jawaban sebaliknya.
Ogglas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.