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

136

Я написал службу WCF для .NET 4.0, которая размещена на моей системе Windows 7 x64Ultimate с IIS 7.5. Один из методов службы имеет в качестве аргумента «объект», и я пытаюсь отправить байт [], который содержит изображение. Пока размер файла этой картинки меньше, чем ок. 48КБ, все идет хорошо. Но если я пытаюсь загрузить картинку большего размера, служба WCF возвращает ошибку: (413) Request Entity Too Large. так что, конечно, я потратил 3 часа на поиск сообщения об ошибке, и каждая тема, которую я видел по этой теме, предлагает повысить свойство 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 Manager для установки значения, открыв сайт и перейдя в «Редактор конфигурации» в разделе «Управление». К сожалению, я все еще получаю ошибку Request Entity Too Large, и это очень расстраивает!

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

kipusoep
источник
6
10485760 = 10 МБ, а не 1 МБ
Шон Роуэн

Ответы:

206

Это не проблема IIS, а проблема WCF. WCF по умолчанию ограничивает сообщения до 65 КБ, чтобы избежать атаки типа «отказ в обслуживании» с большими сообщениями. Также, если вы не используете MTOM, он отправляет byte [] в строку, закодированную в 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>
Ладислав Мрнка
источник
8
я установил для maxRectainedMessageSize указанное выше значение, но все равно получаю ту же ошибку .. Слишком большой
объект
11
@ Sandepku- На всякий случай ... У меня была такая же проблема довольно долгое время, а потом я понял, что неправильно назвал имя привязки, поэтому WCF использовал значения по умолчанию вместо значений конфигурации и давал мне точную информацию. та же ошибка.
Адриан Карр
1
Я установил для maxRectainedMessageSize указанное выше значение, но все равно получаю ту же ошибку. Сущность запроса слишком велика. Обязательное имя не пустое. Помогите!
NetSide
2
Спасибо, сэр, это было полезно сразу же! Установка нового значения для maxReceivedMessageSize требует, чтобы такое же значение было установлено для maxBufferSize.
DiligentKarma
1
@Sandepku, если вы используете webhttpbinding для REST, вам может потребоваться сделать имя привязки в <binding> равным bindingConfiguration в <endpoint>
smoothumut
55

У меня была такая же проблема с IIS 7.5 с REST-службой WCF. Попытка загрузить через POST любой файл выше 65 КБ, и он вернет ошибку 413 «Запрос объекта слишком велик».

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

BasicHttpBinding против WsHttpBinding против WebHttpBinding

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

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>
Роберт Барруэко
источник
2
Спасибо, это работало для меня, используя IIS 7.5 с сервисом REST WCF. На самом деле мне нужно было только изменить атрибут maxReceivedMessageSize.
Алекс Юлий
У меня был maxReceivedMessageSize, maxBufferSize добился цели, maxBufferPoolSize показал как недопустимый атрибут.
JabberwockyDecompiler
4
убедитесь, что вы определили имя привязки и сделайте его равным привязке config в конечной точке. Пример: <binding name = "restLargeBinding" maxBufferPoolSize = ..........>. И в настройке сервиса; <конечная точка address = ""inding =" webHttpBinding "bindingConfiguration =" restLargeBinding ".......
сглаживание
2
прекрасно работает, хотя установка
TransferMode
1
@smoothumut Я знаю, что он старый, но bindingConfiguration = "restLargeBinding" помог мне! Кстати, я использую самодостаточный сервис wcf.
ramires.cabral
26

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

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

«Значение должно быть между 0 и 2147483647».

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

Находится в WindowsFOLDER\System32\inetsrv\config(сервер 2008).

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

Согласно комментариям в конфиге, рекомендуется разблокировать разделы с помощью тега местоположения:

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

Том П
источник
1
Уже установив maxReceivedMessageSizeзначение int.MaxValue, это помогло. Интересно, есть ли какие-либо серьезные проблемы с установкой этой опции на int.MaxValue?
Лэнгдон
2
Кто-нибудь знает, относится ли uploadReadAheadSize также к собственным службам WCF, не работающим через IIS? то есть это также проблема, связанная с Windows Server в целом?
antscode
@antscode У меня есть самодостаточный API-интерфейс, и я страдаю от той же проблемы - вы решили эту проблему самостоятельно?
Тревор Даниэль
18

Я получал это сообщение об ошибке, хотя у меня были 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>

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

Люк
источник
1
Спасибо за добавление этого решения! Косвенно решил мою проблему в том, что имя моего контракта изменилось в dev, но это изменение не было должным образом внедрено в производство. Проверка этих настроек позволила устранить мои (413) слишком большие ошибки Entity Request из-за использования настроек размера сообщений по умолчанию.
Дуг Кнудсен
Я очень рад, что это кому-то помогло. Я потратил много времени на это, так что я надеялся, что это сделает чей-то день менее болезненным.
Люк
9

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

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

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

  1. Через cmd или powershell запустите netsh http show sslcert. Это даст вам вашу текущую конфигурацию. Вам захочется как-то сохранить это, чтобы вы могли ссылаться на него позже.
  2. Вы должны заметить, что «Согласовать сертификат клиента» отключен. Это проблема установки; Следующие шаги покажут, как его включить.
  3. К сожалению, нет способа изменить существующие привязки; Вы должны будете удалить это и повторно добавить это. Запустите, netsh http delete sslcert <ipaddress>:<port>где <ipaddress>:<port>находится IP: порт, показанный в конфигурации, которую вы сохранили ранее.
  4. Теперь вы можете повторно добавить привязку. Здесь вы можете просмотреть действительные параметры 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, вы повторите процедуру для каждой из них. Надеюсь, это поможет кому-то сэкономить часы и часы головной боли, вызванной этой проблемой.

РЕДАКТИРОВАТЬ: По моему опыту, вы не можете запустить netsh http add sslcertкоманду из командной строки напрямую. Вам нужно будет сначала ввести приглашение netsh, набрав, netshа затем выполнить команду, http add sslcert ipport=...чтобы она заработала.

oconnerj
источник
Спасибо за пост, это помогло изолировать проблему для нас, отключение SSL устраняет ошибку WCF. К сожалению, клиентские переговоры не изменили наш результат для работы через SSL. Стил ищет другие биты для переключения :-(
Jafin
8

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

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost
Анас
источник
Вы размещаете свой WCF в среде SharePoint? и вам пришлось перезапустить IIS после применения изменений?
theITvideos
2

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

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

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

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

отворот
источник
1
Ваш вывод о SSL и 'uploadReadAheadSize' очень хорош!
Learner
1

Для всех, кто когда-либо искал ошибку 413 WCF IIS: запросить объект большого размера и использовать службу WCF в Sharepoint, эта информация для вас. Параметры в приложении host и 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

Риккардо Гоцци
источник
1

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

Хан Эверс
источник
1

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

rekna
источник
0

для проблемы удаленный сервер возвратил неожиданный ответ: (413) Слишком большой объект запроса на 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>

asawin
источник
0

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

<services>
  <service name="My.Namespace.ServiceName"> <!-- Updated name -->
    <endpoint address="" 
              binding="wsHttpBinding" 
              bindingConfiguration="MyBindingConfiguratioName" 
              contract="My.Namespace.Interface" <!-- Updated contract -->
    />
  </service>
</services>
Владимир Венегас
источник
0

Получил похожую ошибку на IIS Express с Visual Studio 2017.

Ошибка HTTP 413.0 - слишком большой объект запроса

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

Наиболее вероятные причины:

  • Веб-сервер отказывается обслуживать запрос, поскольку объект запроса слишком велик.

  • Веб-сервер не может обслуживать запрос, потому что он пытается согласовать сертификат клиента, но объект запроса слишком велик.

  • URL-адрес запроса или физическое сопоставление с URL-адресом (т. Е. Путь физической файловой системы к содержимому URL-адреса) слишком длинный.

Вещи, которые вы можете попробовать:

  • Убедитесь, что запрос действителен.

  • Если вы используете клиентские сертификаты, попробуйте:

    • Увеличение system.webServer/serverRuntime@uploadReadAheadSize

    • Настройте конечную точку SSL для согласования клиентских сертификатов как части начального рукопожатия SSL. (netsh http add sslcert ... clientcertnegotiation = enable) .vs \ config \ applicationhost.config

Решите это, отредактировав \.vs\config\applicationhost.config. Переключение serverRuntimeиз Denyк Allowследующим образом:

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

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

Ошибка HTTP 500.19 - внутренняя ошибка сервера

Запрашиваемая страница недоступна, потому что связанные данные конфигурации для этой страницы недействительны.

Этот раздел конфигурации не может быть использован по этому пути. Это происходит, когда раздел заблокирован на родительском уровне. Блокировка либо по умолчанию (overrideModeDefault = "Deny"), либо устанавливается явно с помощью тега местоположения с overrideMode = "Deny" или устаревшим allowOverride = "false".

Затем отредактируйте Web.configсо следующими значениями:

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...
Ogglas
источник
Если вы проголосовали, скажите, пожалуйста, почему. Очень сложно улучшить ответы иначе.
Огглас