Объект запроса HTTP 413 слишком велик в службе WCF с самостоятельным размещением

У меня есть собственная служба WCF, принимающая сообщения через HTTPS.

Сообщение отправляется из приложения Java, которое получает ответ:

HTTP/1.1 413 Request Entity Too Large
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Date: Wed, 19 Sep 2012 09:05:34 GMT
Connection: close

Я не пытаюсь загрузить файл, просто отправляю сообщение XML/SOAP размером 78 КБ. Я попытался увеличить максимальное количество сообщений и размеров буфера, но безрезультатно.

  <binding name="SecuredNoProxy" openTimeout="00:00:10" sendTimeout="00:00:10">
      <textMessageEncoding messageVersion="Soap11WSAddressing10" />
      <security includeTimestamp="true" enableUnsecuredResponse="true">
          <localClientSettings timestampValidityDuration="00:15:00" />
      </security>
      <httpsTransport manualAddressing="false" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" allowCookies="false" bypassProxyOnLocal="true" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true" realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="false" requireClientCertificate="true" />
  </binding>

Пожалуйста, дайте мне знать, если я могу предоставить любую дополнительную информацию.

Журнал трассировки WCF

Получение байтов при соединении «https://localhost»

Граница активности (начало)

Информация о подключении

Генерация исключения (Ошибка)

Исключение составляет:

System.ServiceModel.ProtocolException, System.ServiceModel, версия = 4.0.0.0, культура = нейтральная


https c# wcf self-hosting
person Fenton    schedule 19.09.2012    source источник
comment
Включите трассировку WCF, чтобы проверить, сообщение обрабатывается WCF или нет. Это сообщение выглядит так, как будто оно исходит от хост-компонента HTTP, а не от сантехники WCF.   -  person Sixto Saez    schedule 19.09.2012
comment
@SixtoSaez - я добавил информацию журнала трассировки WCF.   -  person Fenton    schedule 19.09.2012

Ответы (2)


arrow_upward
7
arrow_downward

Как я ускользнул в вопросе, это очень сильно связано с конфигурациями привязки. В частности, maxReceivedMessageSize.

maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647"

Это правильная область для изменения (вероятно, не для того, чтобы делать вещи такими большими, поскольку это сделает вас потенциально уязвимыми для атак типа «отказ в обслуживании»). Определите разумное значение на основе ваших фактических сообщений.

Исходящая конечная точка была правильно настроена, а входящая конечная точка — нет.

<httpsTransport requireClientCertificate="true" />

Это означало, что он использовал значение по умолчанию 65536, которого недостаточно для отправляемого сообщения. Так что это действительно случай очень тщательной проверки конечных точек, особенно если они называются одинаково.

person Fenton    schedule 19.09.2012
comment
Стив, я знаю, что прошло много времени с тех пор, как вы ответили на этот вопрос, но не могли бы вы уточнить, что вы имели в виду под исходящими и входящими конечными точками? Спасибо. - person antscode; 05.03.2014
comment
Все это немного туманно. Слава богу, что есть легкие REST-сервисы, мне давно не приходилось сталкиваться с подобными вещами. Несмотря на это, я имел в виду исходящий = сервис и входящий = вызывающий (думаю!) - person Fenton; 05.03.2014

arrow_upward
2
arrow_downward

Для меня это было maxRequestLength в system.web:

<system.web>
    <compilation debug="true" targetFramework="4.0" />
    <customErrors mode="Off"/>
    <httpRuntime
        maxRequestLength="2147483647"
        executionTimeout="300" />
</system.web>
person Jim Neff    schedule 17.04.2013