2009-09-29 9 views
13

Mam utworzoną przykładową aplikację asp.net i próbuję skrobać dane z mojego serwera za pomocą httpwebrequest. Ale czasami mam powyższy błąd. Zrobiłem kilka wyszukiwań w Google, ale wszyscy mówią, że powinieneś dodać właściwość "<httpWebRequest useUnsafeHeaderParsing="true" />" w web.config.HttpWebRequestError: Serwer popełnił naruszenie protokołu. Sekcja = ResponseHeader Detail = CR musi następować po LF

Ta właściwość ma słowo "NIEAKTYWNE", więc jestem zbyt zmartwiony tym. Nie mogę dodać, że jest to w mojej konfiguracji strony Czy istnieje jakakolwiek inna opcja odczytania odpowiedzi na mój zbędny adres URL. Daj mi znać jak to może być możliwe bez „<httpWebRequest useUnsafeHeaderParsing="true" />

góry dzięki, Laxmilal Menaria

+0

Widziałem inną sprawę z tym samym błędem - mechanizm buforowania próbował ukryć określoną odpowiedź ([Invasion's Incapsula] (https://www.incapsula.com/cdn-content-delivery-network/caching.html) . , więc zamiast przekierować na prawdziwy serwer, * Incapsula * odpowiedziała z tą samą odpowiedzią, ale w jakiś sposób nagłówki były trochę inne i nie były zgodne z Windows CR-LF (\ r \ n). – itsho

Odpowiedz

19

pewno jest to serwer problem-- serwer nie jest zgodnie ze specyfikacją HTTP i klient .NET jest słabnącym to jako potencjalny problem. "Niebezpieczny" jest trochę niepoprawny, nie ma tu dużego problemu z bezpieczeństwem, tylko niezgodność z RFC, która jest zła, ale niestety nie rzadko spotykany.

Tak, jak znaleźć w Google, tak aby ominąć problemu jest zastosowanie następujące zmiany konfiguracji:

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

Jeśli zastanawiasz się, gdzie to dodać, zajrzyj do eksploratora rozwiązań dla 'App.config'. –

2

Jednym ze sposobów debugowania to (i upewnić się, że jest to naruszenie protokół jest przyczyną problemu), należy użyć Fiddler (Http Web Proxy) i sprawdzić, czy ten sam błąd występuje. Jeśli tak nie jest (tzn. Fiddler rozwiązał problem dla ciebie), powinieneś być w stanie to naprawić za pomocą flagi UseUnsafeHeaderParsing.

Jeśli szukasz sposobu, aby ustawić tę wartość programowo zobacz przykłady tutaj: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline/

2

Inna możliwość: kiedy robi POST, serwer odpowiada 100 nadal błędny sposób.

To rozwiązało problem dla mnie:

request.ServicePoint.Expect100Continue = false;

Powiązane problemy