(413) Запросить сущность слишком большой | UploadReadAheadSize

Я написал службу WCF с .NET 4.0, которая размещена на моей системе Windows 7 x64 Ultimate с IIS 7.5. Один из методов службы имеет "объект" в качестве аргумента, и я пытаюсь отправить байт [], содержащий изображение. Пока размер файла этого изображения меньше ок. 48 КБ, все идет хорошо. Но если я пытаюсь загрузить увеличенное изображение, служба WCF возвращает ошибку: (413) Request Entity Too Large. Так что, конечно, я потратил 3 часа на поиск сообщения об ошибке Google, и каждая тема, которую я видел по этому вопросу, предполагает повышение свойства uploadReadAheadSize. Итак, я сделал следующие команды (10485760 = 10 МБ):

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

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

Я также использовал диспетчер IIS для установки значения, открыв сайт и перейдя в "Редактор конфигурации" под управлением. К сожалению, я все еще получаю сообщение об ошибке Entity Too Large, и это действительно расстраивает!

И кто-нибудь знает, что еще я могу попытаться исправить эту ошибку?

ОТВЕТЫ

Ответ 1

Это не проблема IIS, а проблема WCF. WCF по умолчанию ограничивает сообщения до 65 КБ, чтобы избежать атаки на отказ в обслуживании большими сообщениями. Также, если вы не используете MTOM, он отправляет байт [] в кодировку base64 (увеличение на 33%) = > 48 КБ * 1,33 = 64 КБ

Чтобы решить эту проблему, вы должны перенастроить свою службу, чтобы принимать более крупные сообщения. Ранее эта проблема вызывала ошибку 400 Bad Request, но в новой версии WCF начал использовать 413, который является правильным кодом состояния для этого типа ошибок.

Вам нужно установить maxReceivedMessageSize в свой привязку. Вам также может потребоваться установить readerQuotas.

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

Ответ 2

У меня была такая же проблема с IIS 7.5 с помощью службы WCF REST. Попытка загрузить через POST любой файл выше 65k, и он вернет Error 413 "Request Entity too large".

Первое, что вам нужно понять, - это то, какой тип привязки вы настроили в web.config. Вот отличная статья...

BasicHttpBinding против WsHttpBinding vs WebHttpBinding

Если у вас есть служба REST, вам необходимо настроить его как "webHttpBinding". Здесь исправление:

<system.serviceModel>

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

Ответ 3

У меня была та же проблема, и установка uploadReadAheadSize решила его:

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

"Значение должно быть от 0 до 2147483647."

Легко установить его в applicationHost.config-fle, если вы не хотите делать cmd-вещь.

Он расположен в WindowsFOLDER\System32\inetsrv\config (сервер 2008 года).

Вы должны открыть его с помощью блокнота. Сначала создайте резервную копию файла.

В соответствии с комментариями в config рекомендуемым способом разблокировки разделов является использование тега местоположения:

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

Таким образом, вы можете писать внизу (поскольку он не существует раньше). Я пишу maxvalue здесь - напишите свое собственное значение, если хотите.

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

Если вы положили его до </configuration>, например, вы знаете, где у вас есть.

Надеюсь, что решает ваши проблемы. Для меня это была проблема с SSL-покрытием, где слишком много сообщений о замораживании приложения, что привело к ошибке (413) Request Entity Too Large.

Ответ 4

Я получал это сообщение об ошибке, хотя у меня были настройки max, установленные в привязке моего конфигурационного файла службы 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>

Казалось, что эти параметры привязки не применяются, поэтому появляется следующее сообщение об ошибке:

IIS7 - (413) Запросить сущность слишком сильно при подключении к службе.

.

Проблема

Я понял, что атрибут name="" в теге <service> web.config является не свободным текстовым полем, как я думал. Это полное имя реализации контракта на обслуживание, как указано в этой странице документации.

Если это не соответствует, настройки привязки не будут применены!

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

Надеюсь, это спасет кого-то от боли...

Ответ 5

Это помогло мне решить проблему (одна строка - split для удобочитаемости/возможности копирования):

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

Ответ 6

Если вы столкнулись с этой проблемой, несмотря на попытки всех решений в этом потоке, и вы подключаетесь к службе через SSL (например, https), это может помочь:

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

Подводя итог (в случае, если ссылка затухает в будущем), если ваши запросы достаточно велики, согласование сертификатов между клиентом и службой произойдет случайным образом. Чтобы этого не произошло, вам нужно включить определенные настройки в ваших привязках SSL. С вашего сервера IIS выполните следующие действия:

  • Через cmd или powershell запустите netsh http show sslcert. Это даст вам текущую конфигурацию. Вы захотите сохранить это как-то, чтобы впоследствии ссылаться на него позже.
  • Вы должны заметить, что "Negotiate Client Certificate" отключен. Это проблема настройки; следующие шаги покажут, как включить его.
  • К сожалению, нет способа изменить существующие привязки; вам придется удалить его и повторно добавить. Запустите netsh http delete sslcert <ipaddress>:<port>, где <ipaddress>:<port> - это IP-порт, показанный в ранее сохраненной конфигурации.
  • Теперь вы можете повторно добавить привязку. Вы можете просмотреть действительные параметры для netsh http add sslcert здесь (MSDN), но в большинстве случаев ваша команда будет выглядеть так:

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

Если у вас несколько привязок SSL, вы будете повторять процесс для каждого из них. Надеюсь, это поможет спасти кого-то еще часы и часы головной боли, вызванные этой проблемой.

EDIT: По моему опыту, вы не можете запустить команду netsh http add sslcert из командной строки напрямую. Сначала вам нужно ввести запрос netsh, набрав netsh, а затем выпустите команду, как http add sslcert ipport=..., чтобы она работала.

Ответ 7

Для всех, кто когда-либо ищет ошибку WCF IIS 413: запрашивать сущность крупным и использовать службу WCF в Sharepoint, это информация для вас. Параметры в хосте приложения и web.config, предлагаемые в других сайтах/сообщениях, не работают в SharePoint, если вы используете MultipleBaseAddressBasicHttpBindingServiceHostFactory. Вы можете использовать SP Powershell для получения службы SPWebService.Content, создать новый объект SPWcvSettings и обновить настройки, как указано выше для вашей службы (они не будут существовать). Не забудьте просто использовать имя службы (например, [yourservice.svc]) при создании и добавлении настроек. См. Этот сайт для получения дополнительной информации https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

Ответ 8

В моем случае мне пришлось увеличить "Максимальный размер полученного сообщения" в поле "Прием" в BizTalk. Это также имеет значение по умолчанию 64K и поэтому каждое сообщение было отброшено BizTAlk, независимо от того, что я настроил в своем web.config

Ответ 9

Я смог решить это, выполнив фиктивный вызов (например, IsAlive, возвращающий true) непосредственно перед запросом с большим контентом на том же канале/клике wcf. По-видимому, переговоры ssl выполняются при первом вызове. Поэтому нет необходимости увеличивать размер загружаемого файла.

Ответ 10

Для меня установка параметра uploadReadAheadSize в int.MaxValue также устранила проблему, также увеличив ограничения на привязку WCF.

Кажется, что при использовании SSL весь объект сущности запроса предварительно загружен, для которого используется это свойство метабазы.

Для получения дополнительной информации см.:

Страница не отображалась, поскольку объект запроса слишком велик. iis7

Ответ 11

для выдачи удаленный сервер возвратил неожиданный ответ: (413) Request Entity Too Large на WCF с Resful

см. мою конфигурацию объяснения

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

Ответ 12

В моем случае я получал это сообщение об ошибке, потому что я изменил пространство имен служб, а тег служб был указан в более раннем пространстве имен. Я обновил пространство имен, и ошибка исчезла:

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