HTTP 413 Entité de Demande Trop Grande Dans l'Auto-Hébergement, Service WCF

J'ai un auto-hébergement, service WCF accepter les messages via le protocole HTTPS.

Un message est envoyé à partir d'une application Java, qui reçoit la réponse:

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

Je ne suis pas en essayant de télécharger un fichier, il suffit d'envoyer un XML/SOAP message, qui est 78kb. J'ai essayé de monter mon max de message et les tailles de tampon, mais en vain.

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

S'il vous plaît laissez-moi savoir si je peux fournir toutes les informations complémentaires.

WCF Journal de suivi

Recevoir des octets sur la connexion "https://localhost'

Activité frontière (Démarrer)

Informations de connexion

Lancer une exception (Erreur)

L'exception est la suivante:

Système.ServiceModel.ProtocolException, Système.ServiceModel, Version=4.0.0.0, Culture=neutral

Activer WCF Traçage pour voir si le message est en cours de traitement par la WCF ou pas. Ce message ressemble à son provenant de l'hôte HTTP composant, pas la WCF de plomberie.
J'ai ajouté la WCF journal de suivi de l'information.

OriginalL'auteur Fenton | 2012-09-19

  1. 7

    Comme je l'ai échappé à la question, c'est très liée à la configurations de liaison. En particulier, maxReceivedMessageSize.

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

    C'est le bon endroit pour changer (probablement de ne pas faire les choses tout à fait ce gros même si, comme il vous laissera potentiellement vulnérables à des attaques par déni de service). Déterminer un bon de la valeur en fonction de vos messages.

    De la sortie du point de terminaison a été correctement configuré, mais le trafic de terminaison ne l'était pas, c'était:

    <httpsTransport requireClientCertificate="true" />

    Ce qui signifiait qu'il était à l'aide de la valeur par défaut de 65536, ce qui n'est pas suffisant pour que le message soit envoyé. Donc, il est vraiment un cas de contrôle les points de terminaison vraiment avec soin, surtout si elles sont du même nom.

    Steve, je sais que ça a été un moment depuis que vous avez répondu, mais pourriez-vous élaborer sur ce que vous avez voulu dire en sortant vs entrant points de terminaison? Merci.
    C'est un peu de brume. Dieu merci, léger REPOS, services de je n'ai pas eu à regarder ce genre de chose pour un certain temps. Malgré cela, je voulais dire "sortant" = "le service" et les "entrants" = "l'appelant" (je pense!)

    OriginalL'auteur Fenton

  2. 2

    Pour moi, c'était maxRequestLength sous système.web:

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

    OriginalL'auteur Jim Neff