2012-09-19 11 views
8

Posiadam samoobsługową usługę WCF akceptującą wiadomości przez HTTPS.HTTP 413 Żądaj zbyt dużej jednostki samoobsługowej usługi WCF

Komunikat jest wysyłany z aplikacji Java, który otrzymuje odpowiedź:

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 

Ja nie próbuje przesłać plik, wystarczy wysłać wiadomość SOAP/XML, który jest 78kb. Próbowałem upping mój maksymalny rozmiar wiadomości i bufora, ale bez skutku.

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

Proszę dać mi znać, czy mogę podać dodatkowe informacje.

WCF dziennika śledzenia

Otrzymuj bajtów na połączenie 'https: // localhost'

aktywny granicę (Start)

informacje o połączeniu

Throwing wyjątek (błąd)

Wyjątkiem jest:

System.ServiceModel.ProtocolException, System.ServiceModel, Version = 4.0.0.0, Culture = neutral

+0

Aktywne [WCF śledzenia] (http://msdn.microsoft.com/en-us/library/ms733025 (v = vs.100) .aspx), aby zobaczyć, czy wiadomość jest przetwarzana przez WCF czy nie. Ta wiadomość wygląda tak, jakby pochodziła z hosta HTTP, a nie z WCF. –

+0

@SixtoSaez - dodałem informacje dziennika śledzenia WCF. – Fenton

Odpowiedz

6

Jak wymykała się w pytaniu, jest bardzo pokrewny do konfiguracji wiązania. W szczególności maxReceivedMessageSize.

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

To jest właściwy obszar do zmiany (prawdopodobnie nie do rzeczy dość duży, choć jak to będzie zostawić potencjalnie narażone na ataki Denial of Service). Określ rozsądną wartość na podstawie rzeczywistych wiadomości.

Punkt końcowy wychodzące został skonfigurowany poprawnie, ale końcowy przychodzące nie było - było:

<httpsTransport requireClientCertificate="true" /> 

co oznaczało, że był przy użyciu domyślnej wartości 65536, co nie wystarcza na wiadomość jest wysyłana. Tak naprawdę jest to kwestia dokładnego sprawdzenia punktów końcowych, szczególnie jeśli są one podobnie nazwane.

+1

Steve Wiem, że minęło trochę czasu, odkąd odpowiedziałeś na to pytanie, ale czy mógłbyś wyjaśnić, co rozumiesz przez wychodzące kontra końcowe punkty końcowe? Dzięki. – antscode

+1

To wszystko jest trochę mgiełki. Dzięki Bogu za lekkie usługi REST, od jakiegoś czasu nie musiałem patrzeć na takie rzeczy. Mimo to miałem na myśli "wychodzące" = "usługa" i "przychodzące" = "osoba dzwoniąca" (myślę!) – Fenton

2

Dla mnie było maxRequestLength pod system.Web:

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