Получение «базовое соединение было закрыто» на HttpWebRequest - PullRequest
8 голосов
/ 17 августа 2010

У меня есть приложение, написанное на VB.NET ( НЕ asp.net, это консольное приложение Windows).Я пытаюсь вызвать URL-адрес (HTML-страницу) и получить ответ в виде строки.Ответ прямой JSON, никаких HTML-тегов.Он открывается с { и закрывается с }.

Я прекрасно создаю объект HttpWebRequest.Затем позвоните req.GetResponse().Как только я это делаю, я получаю сообщение об ошибке The underlying connection was closed: The connection was closed unexpectedly. Я гуглю и проверяю стекопоток и перепробовал все, что мне удалось найти (во многом это связано с конфигурациями служб WCF, которые неприменимы).

Вот мой код:

Public Function GetJSON(ByRef d As db.Device) As Boolean
    Try
        d.Url = "http://" & d.IpAddress & ini.doc.<svc>.<url>.Value

        Dim req As HttpWebRequest = HttpWebRequest.Create(d.Url)
        // req.Accept = "*/*"
        // req.Timeout = 30000
        // req.ReadWriteTimeout = 30000
        // req.KeepAlive = False
        // req.UseDefaultCredentials = True
        // req.CachePolicy = HttpWebRequest.DefaultCachePolicy
        // req.Proxy = HttpWebRequest.DefaultWebProxy
        // req.ProtocolVersion = New System.Version(1, 0)

        Dim rsp As HttpWebResponse = req.GetResponse()

        Return True
    Catch ex As Exception
        Log(ex.Message)
        Return False
    Finally
        rsp = Nothing
        req = Nothing
    End Try
End Function

Закомментированные строки (неправильный стиль комментария, но поэтому SO будет правильно его анализировать) - все, что я до сих пор пробовал, основываясь на том, чтоЯ нашел в Интернете.Никто из них не исправил это.Я проверил, что созданный URL-адрес правильный;если я вызываю точно такой же URL в моем браузере, он возвращает точно правильный ожидаемый ответ.

Я пытался поджечь его ... и я вижу фактические ожидаемые, полные данные возвращаются в выводе акулы, затем несколько строк, а затем красная линия, которая говорит: http > 51943 [RST] Seq=1607 Win=0 Len=0, чтопоследняя строка, отображаемая перед .NET, выдает ошибку.

Я также попытался включить System.Net трассировку / ведение журнала для каждого сообщения здесь на SO, и в выходном файле, из которого я вижу аналогичным образом все ожидаемые данные JSON возвращается , нопосле возвращения он выдает следующие строки в журнале трассировки .NET:

System.Net.Sockets Verbose: 0 : [7040] Exiting Socket#60467532::Receive()   -> 1605#1605
System.Net.Sockets Verbose: 0 : [7040] Socket#60467532::Receive()
System.Net.Sockets Verbose: 0 : [7040] Data from Socket#60467532::Receive
System.Net.Sockets Verbose: 0 : [7040] 00000000 :                                                 : 
System.Net.Sockets Verbose: 0 : [7040] Exiting Socket#60467532::Receive()   -> 0#0
System.Net.Sockets Verbose: 0 : [7040] Socket#60467532::Dispose()
System.Net Error: 0 : [7040] Exception in the HttpWebRequest#27806816:: - The underlying connection was closed: The connection was closed unexpectedly.
System.Net Error: 0 : [7040] Exception in the HttpWebRequest#27806816::GetResponse - The underlying connection was closed: The connection was closed unexpectedly.

Есть идеи, куда идти дальше, чтобы попытаться выяснить это?Мы читаем эти данные с некоторых сенсорных устройств мониторинга окружающей среды, и они дали нам этот URL для использования.

Две вещи, которые действительно меня заводят и смущают, это то, что
а) он отлично работает при вызове в браузере
б) и трассировка WireShark и .NET фактически отображают все данные IS возвращается, и фреймворк по какой-то причине исключает ПОСЛЕ получения всех данных!

Само по себе WebException очень мало используется, поскольку его InnerException равно нулю, а его Status просто говорит "ConnectionClosed {8}"

Заранее спасибо !!!

ОБНОВЛЕНИЕ 08/18 1130: Я также пытался использовать только System.Net.WebRequest вместо HttpWebRequest.Это также не имело никакого значения.

ОБНОВЛЕНИЕ 08/18 1222: Я просто попытался переключить свой код вместо использования [Http]Web[Request|Response] для уменьшения яркости объекта WebClient и использования егоDownloadString() метод.Однако при этом также выдает точно такую ​​же ошибку.

ОБНОВЛЕНИЕ 08/18 1230: При использовании My.Computer.Network.DownloadFile() - также возникает ошибка закрытия того же соединения.

Ответы [ 6 ]

5 голосов
/ 18 августа 2010

Можете ли вы опубликовать все содержимое журнала трассировки на pastebin.com и разместить ссылку здесь?

Возможно, вы получаете это исключение, поскольку сервер может указать в заголовке «Content-Length», чтоотправляет N байтов объекта, но фактически отправляет меньше N байтов и закрывает соединение.

Ответ:

Спасибо за данные.Из трассировки и трассировки проволоки видно, что сервер не отправляет заголовки ответа, а непосредственно отправляет данные.Это нарушение протокола HTTP.Вот почему клиент выдает исключение.

3 голосов
/ 14 декабря 2010

Это помогает мне. Надеюсь, это кому-то тоже поможет.

Сразу после создания объекта HttpWebRequest, добавить эту строку.

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;

Что это означает, определяет Secure Socket Layer (SSL) 3.0 в качестве протокола безопасности

http://support.microsoft.com/kb/915599

3 голосов
/ 20 августа 2010

Вот как я это заработал ... Спасибо feroze за то, что указал мне правильное направление!
(присуждено очков)

Public Function GetJSON(ByRef d As db.Device) As Boolean
    Try
        Dim tcp = New TcpClient()
        tcp.Connect(d.IpAddress, 80)

        Dim ns = tcp.GetStream()

        Dim req As Byte() = System.Text.Encoding.ASCII.GetBytes(
            "GET /getdata.htm HTTP/1.1" & vbCrLf & vbCrLf
        )
        ns.Write(req, 0, req.Length)

        Dim rsp(2048) As Byte, rcv As Integer
        Do
            rcv = ns.Read(rsp, 0, rsp.Length)
            d.JSON &= System.Text.Encoding.ASCII.GetString(rsp, 0, rcv)
        Loop Until rcv = 0

        tcp.Close()

        Return True
    Catch ex As Exception
        Log(ex.Message)
        Return False
    End Try
End Function
0 голосов
/ 25 января 2017

В моем случае проблема заключалась в том, что мы использовали «http: // ..» в качестве адреса службы вместо «https://". ..

0 голосов
/ 03 октября 2014

У меня была такая же проблема с запросом БЕЗ тела. В моем случае установка ContentLength в ноль устранила проблему.

0 голосов
/ 06 февраля 2014

Проверьте задержку запроса.Если оно больше нескольких мс, то стоит отключить алгоритм Nagle

 ServicePointManager.UseNagleAlgorithm = false;
...