Serwer popełnił naruszenie protokołu. Sekcja = ResponseStatusLine ERROR

115

Utworzyłem program, próbowałem zamieścić ciąg na stronie i otrzymuję ten błąd:

„Serwer popełnił naruszenie protokołu. Section = ResponseStatusLine”

po tym wierszu kodu:

gResponse = (HttpWebResponse)gRequest.GetResponse();

Jak mogę naprawić ten wyjątek?

c# httpwebrequest

— manish patel
źródło

71

Spróbuj umieścić to w swojej aplikacji / web.config:

<system.net>
    <settings>
        <httpWebRequest useUnsafeHeaderParsing="true" />
    </settings>
</system.net>

Jeśli to nie zadziała, możesz również spróbować ustawić KeepAlivewłaściwość na false.

— Darin Dimitrov
źródło

3

Miałem 6 adresów URL rzucających ten błąd. Ustawienie useUnsafeHeaderParsing naprawiło to dla jednego łącza, ale ustawienie KeepAlive = false naprawiło to dla wszystkich 6.

— David Hammond,

3

To samo można umieścić w tagu głównym <configuration> w App.copnfig dla aplikacji innych niż internetowe (na przykład naprawiłem w ten sposób aplikację WPF - dzięki!).

— Yury Schkatula

ktoś wie, dlaczego ten środek bezpieczeństwa jest nakładany przez IIS? Zadziałało, ale nie rozumiem powodu ograniczenia wartości nagłówka (ręczne ustawienie ich w moim przypadku).

— emran

26

Ma to na celu jedynie uniknięcie problemu, a nie jego naprawę. Myślę, że nie powinno to być domyślne rozwiązanie.

— Tobias

4

Zgadzam się z Tobiaszem - unikasz problemu. Może się zdarzyć, że problem występuje na serwerze, którego nie możesz naprawić, a zatem unikanie może być jedyną opcją ... ale mimo to wyjaśnijmy różnicę między unikaniem błędu protokołu a jego naprawą.

— metaforge

58

Czasami ten błąd występuje, gdy UserAgentparametr żądania jest pusty (w moim przypadku w interfejsie API github.com).

Ustawienie tego parametru na niestandardowy niepusty ciąg rozwiązało mój problem.

— Ivan Kochurkin
źródło

5

Ach, tego potrzebowałem. Dzięki. Oto przykład

— klienta

Szybka linia do użycia WebClienttutaj stackoverflow.com/a/11841680/4795214

5

Dzięki. Jeśli chcesz zapytać GitHub za pomocą HttpClient add: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); line for fix.

— Cihan Yakar

32

W moim przypadku winowajcą było zwrócenie No Contentodpowiedzi, ale zdefiniowanie treści odpowiedzi w tym samym czasie. Niech ta odpowiedź przypomni mi i może innym, abyNoContent nigdy więcej nie odpowiadali z ciałem .

To zachowanie jest zgodne z 10.2.5 204 bez zawartości w specyfikacji HTTP , który mówi:

Odpowiedź 204 NIE MOŻE zawierać treści wiadomości i dlatego jest zawsze zakończona pierwszą pustą linią po polach nagłówka.

— Tobias
źródło

Po prostu przeczytaj to po tym, jak The server committed a protocol violation. Section=ResponseStatusLine wystąpił błąd podczas używania WebApi do zwrócenia niestandardowej NoContent()odpowiedzi, która była wysyłana No Contentw odpowiedzi z jakiegoś dziwnego powodu! Kiedy to wyjęłam, problem zniknął :)

— Intrepid

2

To też był mój problem, chociaż był trudny, ponieważ zawiodło wywołanie PO odpowiedzi na brak treści.

— mdickin

Naprawiono przez usunięcie someContentz return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1

— snippetkid

12

Inna możliwość: podczas wykonywania POST serwer odpowiada 100 kontynuuj w nieprawidłowy sposób.

To rozwiązało problem dla mnie:

request.ServicePoint.Expect100Continue = false;

— marq
źródło

To zadziałało podczas uzyskiwania dostępu do API MediaFire.

— AlexPi,

3

Wiem, że się spóźniam, ale co masz na myśli mówiąc „w niewłaściwy sposób”?

— kuskmen

1

Dla każdego, kto używa HttpClient , zadziałało dla mnie:var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;

— user2444499

9

To się działo, gdy miałem Skype'a na moim komputerze lokalnym. Jak tylko zamknąłem, wyjątek zniknął.

Pomysł dzięki uprzejmości tej strony

— Łukasz
źródło

Miał ten sam problem. Okazało się, że to Skype. Jest to tak niefortunne, że nie można dostarczyć odpowiednich komunikatów.

— jordan koskei

w rzeczywistości nie musisz zamykać Skype'a, dodałem odpowiedź poniżej, aby pokazać, jak sobie z tym poradzić bez zamykania Skype.

— AltF4_

8

Jednym ze sposobów debugowania tego (i upewnienia się, że przyczyną problemu jest naruszenie protokołu), jest użycie programu Fiddler (serwer proxy sieci Web Http) i sprawdzenie, czy występuje ten sam błąd. Jeśli tak się nie stanie (tj. Fiddler załatwił problem za Ciebie), powinieneś być w stanie go naprawić za pomocą flagi UseUnsafeHeaderParsing.

Jeśli szukasz sposobu na programowe ustawienie tej wartości, zapoznaj się z przykładami tutaj: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /

— Dinis Cruz
źródło

Fiddler rzeczywiście naprawia problem, który mam z żądaniem GET HTTP. Czy możemy zobaczyć, co robi skrzypek?

— Olivier MATROT

8

Wiele rozwiązań mówi o obejściu, ale nie o rzeczywistej przyczynie błędu.

Jedną z możliwych przyczyn tego błędu jest to, że serwer WWW używa kodowania innego niż ASCIIlub ISO-8859-1do wyprowadzenia sekcji odpowiedzi nagłówka. Powodem ISO-8859-1byłoby użycie Response-Phraserozszerzonych znaków łacińskich.

Inną możliwą przyczyną tego błędu jest to, że serwer WWW używa, UTF-8który generuje znacznik kolejności bajtów (BOM). Na przykład, domyślna stała Encoding.UTF8wyprowadza BOM i łatwo o tym zapomnieć. Strony internetowe będą działać poprawnie w Firefoksie i Chrome, ale HttpWebRequestbędą bombardować :). Szybką naprawą jest zmiana serwera WWW, aby używał kodowania UTF-8, które nie generuje BOM, np. new UTF8Encoding(false)(Co jest OK, o ile Response-Phrasetylko zawiera znaki ASCII, ale tak naprawdę powinno używać ASCIIlub ISO-8859-1dla nagłówków, a następnie UTF-8lub inne kodowanie odpowiedzi).

— Odraza
źródło

To najlepsza odpowiedź. Wyjaśnia, dlaczego serwer sieciowy działa nieprawidłowo. Dzięki! (Muszę emulować serwer sieciowy z gniazdami z powodu problemów z wdrażaniem z HttpListener.)

— Andrew Rondeau

6

Ustawienie oczekiwania 100 nadal na fałsz i zmniejszenie czasu bezczynności gniazda do dwóch sekund rozwiązało problem

ServicePointManager.Expect100Continue = false; 
ServicePointManager. MaxServicePointIdleTime = 2000;

— Prashan Pratap
źródło

6

Skype był główną przyczyną mojego problemu:

Ten błąd zwykle występuje, gdy program Visual Studio jest skonfigurowany do debugowania istniejącej aplikacji internetowej działającej w usługach IIS, a nie wbudowanego serwera sieci Web debugowania ASP.NET . Usługi IIS domyślnie nasłuchują żądań sieci Web na porcie 80. W tym przypadku inna aplikacja nasłuchuje już żądań na porcie 80. Zazwyczaj problematyczną aplikacją jest Skype, który domyślnie przejmuje nasłuchiwanie na portach 80 i 443 po zainstalowaniu. Skype zajmuje już port 80. Dlatego IIS nie może się uruchomić.

Aby rozwiązać ten problem, wykonaj następujące czynności:

Skype -> Narzędzia -> Opcje -> Zaawansowane -> Połączenie:

Usuń zaznaczenie opcji „Użyj portów 80 i 443 jako alternatyw dla połączeń przychodzących”.

Jak wskazano poniżej, po wykonaniu resetowania usług IIS .

— AltF4_
źródło

2

i pamiętaj, aby ponownie uruchomić IIS po wykonaniu tej czynności

— Ahmed Galal

3

Próbowałem uzyskać dostęp do Last.fm Rest API zza serwera proxy i otrzymałem ten słynny błąd.

Serwer popełnił naruszenie protokołu. Sekcja = ResponseStatusLine

Po wypróbowaniu kilku obejść, tylko te dwa działały dla mnie

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ProtocolVersion = HttpVersion.Version10;

i

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ServicePoint.Expect100Continue = false;

— nixda
źródło

2

Żadne z rozwiązań nie działało dla mnie, więc musiałem użyć WebClient zamiast HttpWebRequest i problem już nie istniał.

Potrzebowałem użyć CookieContainer, więc skorzystałem z rozwiązania zamieszczonego przez Pavela Savarę w tym wątku - Używanie CookieContainer z klasą WebClient

po prostu usuń „chroniony” z tej linii:

prywatny kontener CookieContainer tylko do odczytu = new CookieContainer ();

— TH Todorov
źródło

2

Prawdopodobną przyczyną tego problemu jest konfiguracja protokołu Web Proxy Auto Discovery Protocol (WPAD) w sieci. Żądanie HTTP zostanie wysłane w sposób przezroczysty do serwera proxy, który może odesłać odpowiedź, której klient nie zaakceptuje lub nie jest skonfigurowany do akceptowania. Przed zhakowaniem kodu na bity sprawdź, czy WPAD nie jest w grze, szczególnie jeśli to „zaczęło się dziać” niespodziewanie.

— Skrymsli
źródło

2

Mój problem polegał na tym, że zadzwoniłem do httpspunktu końcowego z http.

— gneryczny
źródło

1

Pierwszą rzeczą, którą próbowaliśmy, było wyłączenie dynamicznej kompresji treści dla IIS, co rozwiązało błędy, ale błąd nie był spowodowany po stronie serwera i dotyczyło to tylko jednego klienta.

Po stronie klienta odinstalowaliśmy klientów VPN, zresetowaliśmy ustawienia internetowe, a następnie ponownie zainstalowaliśmy klientów VPN. Błąd mógł być również spowodowany przez poprzedni program antywirusowy z zaporą ogniową. Następnie włączyliśmy z powrotem dynamiczną kompresję treści i teraz działa dobrze jak poprzednio.

Wystąpił błąd w niestandardowej aplikacji, która łączy się z usługą internetową, a także w TFS.

— HasanG
źródło

0

W moim przypadku IIS nie miał niezbędnych uprawnień dostępu do odpowiedniej ścieżki ASPX.

Dałem użytkownikowi IIS uprawnienia do odpowiedniego katalogu i wszystko poszło dobrze.

— Vaiden
źródło

0

Zobacz swój kod i sprawdź, czy ustawiasz nagłówek z wartością NULL lub pustą.

— Abdul Rauf
źródło

0

Zacząłem otrzymywać ten błąd z moich usług php JSON / REST

Zacząłem otrzymywać błąd z relativley rzadkich przesyłania POST po dodaniu ob_start("ob_gzhandler")do najczęściej używanego skryptu GET php

Potrafię używać tylko ob_start()i wszystko jest w porządku.

— Patrick
źródło