Httpwebreqest współpracuje z Fiddler On inaczej Timeout

Question

Dostaję dziwny błąd. Mam skonfigurowany skrypt, który działa perfekcyjnie, gdy Fiddler jest otwarty - pobiera raport z witryny za pomocą httpwebrequest i wszystko działa dobrze!

JEDNAK działa tylko wtedy, gdy Skrzypek jest otwarty? Kiedy skrzypek nie działa, po prostu dostaję "Problem z czasem oczekiwania"

Czy ktoś wie, jak to naprawić i sprawić, by działał z moją aplikacją ASP.NET MVC?

Dzięki

Edit: Dzięki za odpowiedzi! Odnośnie serwera proxy - chciałem przetestować ten skrypt na Windows Azure - tak mało mylić, jak skonfigurować domyślne ustawienia proxy?

Answer 1

Należy pamiętać, że Fiddler działa jako proxy. Praca aplikacji, gdy Fiddler działa, ale nie w inny sposób, może wskazywać na problem z domyślną konfiguracją serwera proxy. Otwórz Opcje internetowe (ewentualnie przez IE) i sprawdź ustawienia proxy. W szczególności zwróć uwagę, czy konfigurujesz za pomocą skryptu.

Wspomnę o jednej bardzo nieprawdopodobnej możliwości, choć tak naprawdę mi się to przydarzyło. Na moim komputerze zainstalowałem pewien produkt antywirusowy. Z jakiegoś powodu wydawało mi się, że moja subskrypcja wygasła. W rezultacie oprogramowanie nie działało, a zatem nie mogło aktualizować listy programów, które mają dostęp do Internetu. Programy zainstalowane po wygaśnięciu nie zadziałają, chyba że działa Fiddler (ponieważ Fiddler został zainstalowany przed wygaśnięciem, był na liście "Good"). Każdy inny program zainstalowany po wygaśnięciu był na liście "Zły" (domyślnie).

Answer 2

Czy używasz protokołu HTTPS? Jeśli tak, Twój kod może nie ufać certyfikatowi zdalnego serwisu, a Fiddler może przekazywać dane do Twojej aplikacji. Wyślij nam komunikat o błędzie i minimalną ilość kodu, który replikuje ten problem.

Answer 3

Dla poszukiwaczy tutaj jest inna myśl. Mam aplikację, która manipuluje moją stroną internetową w sposób zrobotyzowany. Aplikacja korzysta z HttpWebRequest i HttpWebResponse w .Net 4.0. Po dwóch lub trzech zakończonych sukcesem działaniach GET następne będą konsekwentnie blokowane. Inny post sugerował, że niewłaściwe zamknięcie HINTERNETa może spowodować, że aplikacja zablokuje się na kolejnym GET-ie na tym samym hoście ze względu na ograniczenie liczby równoległych połączeń z tym samym hostem. Nie wiem, czy to się dzieje pod kołdrą, ale myślałem, że wrócę i ustalę, gdzie mogę zamknąć.

Zamknąłem wszystkie moje obiekty HttpWebResponse w kodzie i mój problem zniknął. Z tego nie rozumiem, dlaczego Skrzypek zamaskował sprawę, ale tak się stało. Przed dodaniem zamknięć konkretne żądanie w sekwencji będzie konsekwentnie przekraczać limit czasu. Po zamknięciu odpowiedzi wszystko się wyjaśniło i mogłem biec bez pośrednictwa przez Skrzypka.

Answer 4

Zamknięcie wszystkich obiektów HttpWebRequest jako @ProfVonLemongargle sugerowało naprawienie tego samego problemu, który miałem.

Fiddler prawdopodobnie zamyka połączenia z serwerem, więc ograniczenie liczby jednoczesnych połączeń jest maskowane, gdy aplikacja używa go jako serwera proxy. Więcej informacji można znaleźć w tym wątku: HttpWebRequest times out on second call

Answer 5

starszy łańcuch, ale odkryłem ten sam problem w naszym kodzie. Było tak dlatego, że w javascript były pozostałe polecenia console.log. Doprowadziło to do zablokowania kodu javascript.

Answer 6

miał ten sam problem w sieci firmowej, otworzyłem Fiddler2 zdiagnozować co było wysyłane/odbierane i problem odszedł! Po dalszych badaniach odkryłem, że Skrzypek tunele ruch przez niego jak serwer proxy i moja sieć korporacyjna wykorzystuje również skryptu automatycznej konfiguracji dla proxy (zakładam Skrzypek został tunelowanie go przez właściwego pełnomocnika systemu, którego moja aplikacja nie wiedziała)

aby uzyskać mój program VB.net działa wszystko, co musiałem zrobić, to dodać ustawienia proxy na życzenie:

Dim proxy = WebRequest.GetSystemWebProxy() 
oRequest.Proxy = proxy