Подтвердить что ты не робот

HttpWebRequest не работает, кроме случаев, когда работает скрипт

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

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();
4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

Это псевдо синхронного кода:

request.create(url);

///codes

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

/// codes again like reading it to a stream

response.close();

Ответ 3

Недавно у меня была аналогичная проблема. 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;
}

Ответ 4

В моем случае, когда у меня была такая же ситуация (POST работает только при запуске Fiddler), код отправляет POST из приложения, работающего на IISExpress, в среде разработки за прокси-сервером на внешний сервер. Очевидно, даже если у вас есть настройки прокси-сервера, настроенные в Internet Options, среда IIS работает, возможно, не имеет к ним доступа. В моей рабочей среде мне просто пришлось обновить web.config с помощью пути к нашей конфигурации прокси-сервера script. Возможно, вам придется настроить другие настройки прокси-сервера. В этом случае ваш друг - это страница 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>

Ответ 5

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

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

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

Ответ 6

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

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

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

Мое подозрение заключается в том, что "Bypass proxy server для локальных адресов" не обязательно воспринимается языком программирования, но данные прокси-сервера. Fiddler знает об этой политике, поэтому запросы через Fiddler работают, но запросы прямо с языка программирования этого не делают.

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

Ответ 7

Я столкнулся с одним и тем же сценарием: я был POSTing до конечной точки за Windows Authentication.

Fiddler хранит пул открытых подключений, но ваш С# test или powershell script не, когда он работает без скрипача.

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

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

Ответ 8

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

Ответ 9

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

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

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

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