HttpWebRequest не работает, кроме случаев, когда запущен fiddler - PullRequest
22 голосов
/ 26 января 2011

Это, наверное, самая странная проблема, с которой я столкнулся.У меня есть кусок кода для отправки POST на URL.Код не работает и не выдает никаких исключений, когда Fiddler не работает. Однако, когда Fiddler работает, код успешно отправляет данные.У меня есть доступ к странице поста, поэтому я знаю, были ли данные размещены или нет.Это, вероятно, очень бессмысленно, но я сталкиваюсь с ситуацией и очень растерялся.

byte[] postBytes = new ASCIIEncoding().GetBytes(postData);
HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://myURL);
req.UserAgent = "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10";
req.Accept = "application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5";
req.Headers.Add("Accept-Charset", "ISO-8859-1,utf-8;q=0.7,*;q=0.3");
req.Headers.Add("Accept-Language", "en-US,en;q=0.8");
req.Method = "POST";
req.ContentType = "application/x-www-form-urlencoded";
req.ContentLength = postBytes.Length;
req.CookieContainer = cc;
Stream s = req.GetRequestStream();
s.Write(postBytes, 0, postBytes.Length);
s.Close();

Ответы [ 10 ]

14 голосов
/ 04 февраля 2011

Если вы не позвоните GetResponseStream(), вы не сможете закрыть ответ.Если вы не закроете ответ, вы получите сокет в плохом состоянии в .NET.Вы ДОЛЖНЫ закрыть ответ, чтобы предотвратить вмешательство в последующий запрос.

7 голосов
/ 26 мая 2012

Закройте HttpWebResponse после получения.

У меня была такая же проблема, затем я начал закрывать ответы после каждого запроса, и Boom, нет необходимости запускать fiddler.

Это псевдо-синхронный код:

request.create(url);

///codes

httpwebresponse response = (httpwebresponse)request.getresponse();

/// codes again like reading it to a stream

response.close();
5 голосов
/ 01 февраля 2012

У меня недавно была похожая проблема. Wireshark показывает, что HTTPWebRequest не покидает клиентский компьютер, если не запущен Fiddler. Я попытался удалить настройки прокси, но это не решило проблему для меня. Я попробовал все, от установки запроса до HttpVersion.Version10, включения / отключения SendChuck, KeepAlive и множества других настроек. Ничего из этого не сработало.

В конце концов, я только что проверил, обнаружил ли .Net прокси и попытался ли его игнорировать. Это исправило мою проблему с request.GetResponse (), выдавшей немедленное исключение.

IWebProxy proxy = request.Proxy;

if (request.Proxy != null)
{
    Console.WriteLine("Removing proxy: {0}", proxy.GetProxy(request.RequestUri));
    request.Proxy = null;
}
3 голосов
/ 14 февраля 2012

В моем случае, когда у меня была такая же ситуация (POST работает, только когда Fiddler работает), код отправлял POST из приложения, работающего на IISExpress в среде разработки за прокси, на внешний сервер. Очевидно, что даже если у вас настроены параметры прокси-сервера в параметрах Интернета, среда, в которой работает IIS, может не иметь к ним доступа. В моей рабочей среде мне просто пришлось обновить web.config путем указания пути к скрипту конфигурации нашего прокси. Возможно, вам потребуется настроить другие параметры прокси . В этом случае ваш друг - это страница MSDN, которая объясняет, что они из себя представляют: http://msdn.microsoft.com/en-us/library/sa91de1e.aspx.

В конечном итоге я включил следующее в web.config приложения, а затем прошел POST.

<configuration>
  <system.net>
    <defaultProxy>
      <proxy scriptLocation="http://example.com:81/proxy.script" />
    </defaultProxy>
  </system.net>
</configuration>
2 голосов
/ 20 июня 2012

Я столкнулся с той же проблемой с Python - запросы к локальному серверу не выполнялись с 404, но затем, когда я запустил их с запущенным Fiddler, они работали правильно.заключается в том, что Fiddler работает как прокси-сервер для HTTP-трафика, поэтому все запросы с локальной машины проходят через Fiddler, а не прямо в сеть.

В той ситуации, в которой я находился, я отправлял запросы на локальный сервер, через прокси проходил обычный трафик, а в Local Area Network (LAN) Settings для сетевого подключения на панели Proxy server была отмечена опция Bypass proxy server for local addresses,

Я подозреваю, что «Обход прокси-сервера для локальных адресов» не обязательно определяется языком программирования, но подробности прокси-сервера таковы.Fiddler знает об этой политике, поэтому запросы через Fiddler работают, а запросы напрямую из языка программирования - нет.

Установив прокси для запроса на локальный сервер в ноль, он корректно работал из кода.Очевидно, что это может быть ошибкой, если вы обнаружите, что переходите с внутреннего на внешний сервер во время развертывания.

2 голосов
/ 26 января 2011

Ну, я столкнулся с подобной проблемой несколько недель назад, и причина была в том, что, когда fiddler работает, он изменяет настройки прокси-сервера для передачи запроса через Fiddler, но когда он закрыт, прокси-сервер как-то все еще остается и, следовательно, не позволяет вашему запросузайдите в интернет.

Я попытался, настроив сетевые настройки IE и Firefox, чтобы не использовать прокси, и это сработало.

Попробуйте это, может быть, та же проблема ...

1 голос
/ 16 сентября 2015

Всегда используйте используя конструкцию.убедитесь, что все ресурсы освобождены после вызова

   using (HttpWebResponse responseClaimLines = (HttpWebResponse)requestClaimLines.GetResponse())
                {
                    using (StreamReader reader = new StreamReader(responseClaimLines.GetResponseStream()))
                    {
                        responseEnvelop = reader.ReadToEnd();
                    }
                }

и добавьте следующие записи в файл webconfig

<system.net>
<connectionManagement>
<add address="*" maxconnection="30"/>

1 голос
/ 22 октября 2013

У нас здесь очень похожая проблема.Мы подключаемся к удаленным сервисам, и они, кажется, почти всегда терпят неудачу.Однако, когда мы прокси через fiddler (с веб-сервера), все работает великолепно.Сейчас мы работаем над отладкой, но, похоже, это очень похожая проблема.

1 голос
/ 23 августа 2013

Я столкнулся с тем же сценарием: я отправлял сообщения в конечную точку за проверкой подлинности Windows.

Fiddler сохраняет пул открытых соединений , но ваш тест C # или сценарий powershell не , когда он работает без fiddler.

Таким образом, вы можете сделать тест / сценарий также для поддержки пула открытых аутентифицированных соединений, установив для свойства UnsafeAuthenticatedConnectionSharing значение true для HttpWebRequest. Прочитайте подробнее об этом здесь, Microsoft KB . В обоих случаях в этой статье вы можете видеть, что они делают два запроса. Первый - это простой GET или HEAD для получения заголовка аутентификации (для завершения рукопожатия), а второй - POST, который будет использовать полученный ранее заголовок.

Очевидно, вы не можете (грусть) напрямую выполнить рукопожатие с запросами POST http.

0 голосов
/ 03 ноября 2018

Я нашел решение в увеличении количества соединений по умолчанию

ServicePointManager.DefaultConnectionLimit = 10000;
...