2013-08-28 9 views
8

Używam klasy HttpClient do komunikowania się z usługą sieciową w mojej aplikacji WPF.C#: HttpClient, Serwer popełnił naruszenie protokołu. Sekcja = ResponseStatusLine

Kiedy wykonuję kolejne żądania GET na tym samym połączeniu, wszystko działa poprawnie. Jednak, gdy wykonuję kolejne żądania PUT/PATCH na tym samym połączeniu, pierwsze żądanie wykonuje się dokładnie i otrzymuję odpowiedź, ale drugie żądanie nie zawiera treści żądania i otrzymuję niesławny błąd "Serwer zatwierdził protokół naruszenie Sekcja = ResponseStatusLine ".

Moje żądania zakończą się pomyślnie, jeśli ręcznie zamknę połączenie po każdym żądaniu, dodając Połączenie: zamknij do nagłówka. To "rozwiązanie" jest złym wzorcem, a wyniki nie będą odpowiednio skalowane.

Poniżej znajduje się debranded wersja wykazu moim Stream TCP wyjściu z żądań wysyłanych:

Wireshark: Śledź Stream TCP Wyjście

GET /domain/api/tenant/current/object?objectName=Lizbot HTTP/1.1 
Accept: application/json 

    HTTP/1.1 200 OK 
    Content-Type: application/json; charset=utf-8 
    Content-Length: 50 
    {"Data":[{"Id":123,"ObjectName":"Lizbot","Date":null}],"Errors":[]} 

PATCH /domain/api/tenant/current/object/123 HTTP/1.1 
Accept: application/json 
Content-Type: application/json; charset=utf-8 
Content-Length: 50 
{"Id":123,"ObjectName":"Lizbot","Date":null} 

    HTTP/1.1 204 No Content 
    Content-Type: application/json; charset=utf-8 
    {"Data":null,"Errors":[]} 

PATCH /domain/api/tenant/current/object/123/otherObject HTTP/1.1 
Accept: application/json 
Content-Type: application/json; charset=utf-8 

    HTTP/1.1 400 Bad Request</b> 
    Content-Type: text/html; charset=us-ascii 
    Connection: close 
    Content-Length: 311 

Zauważ, że druga łata brakuje obiekt, z którym ma łatać. Jeśli zmienię kolejność PATCHINGU, drugi PATCH nadal nie ma obiektu.

Ten błąd wydaje się być powszechny w przypadku kilku znanych rozwiązań, które próbowałem. Składają się z this solution, która obejmuje ustawienie właściwości useUnsafeHeaderParsing na TRUE i ustawienie właściwości Keep-Alive na FALSE w Web.Config. Próbowałem również rozwiązania ustawienia tych właściwości w następujący sposób:

ServicePointManager.DefaultConnectionLimit = 2; 
ServicePointManager.Expect100Continue = false; 

Żadne z tych rozwiązań nie zadziałało. Należy zauważyć, że podczas korzystania z narzędzia proxy Http Debugging, Fiddler, do przechwytywania tych żądań, nie otrzymuję żadnych błędów.

To, o co pytam, to czy ktoś zna dobre rozwiązanie, aby złagodzić ten błąd, abym mógł wykonywać wiele żądań w połączeniu bez utraty treści aktualizacji. Jeśli potrzebujemy więcej informacji, chętnie je dostarczę.

Odpowiedz

6

Podstawowym problemem jest to, że odpowiedź PATCH zawiera treść w treści odpowiedzi. Upewnij się, że serwer nie wysyła treści podczas wysyłania treści bez treści.

+0

Dziękujemy! Akceptuję tę odpowiedź, ponieważ, chociaż moja nie spowoduje odrzucenia błędu, to zapewniam, że nie mam błędów do rzucenia. –

+1

Chociaż zgadzam się, że wysyłanie 204 z treścią jest naruszeniem protokołu, HttpClient może poradzić sobie z tą sytuacją bez żadnego problemu. Podobnie jak samo hostowane api internetowe. Może IIS mylą rzeczy. –

9

Po długim debugowaniu i odczytaniu zdałem sobie sprawę, że próbowałem edytować plik Web.Config aplikacji WPF zamiast pliku app.config!

Jeśli więc upuścisz ten kod w pliku app.config w katalogu głównym znacznika konfiguracji dla aplikacji WPF, rozwiąże to problem.

<system.net> 
<settings> 
<httpWebRequest useUnsafeHeaderParsing = "true"/> 
</settings> 
</system.net> 
Powiązane problemy