Hilfe Schleife in asynchronem Empfänger eliminiert aufgrund Content-Length = 0 in HTTP-Antwort

Question

Einige Webserver zurückkehren Content-Length auf Null gesetzt in den HTTP-Response-Header. Ich möchte eine deterministische und performante Lösung für alle, die Daten in dieser Situation für den Empfang.

URL bekannt dieses Verhalten zeigen (zusätzliche URLs unten):

http: / /www.washingtonpost.com/wp-dyn/content/article/2010/02/12/AR2010021204894.html?hpid=topnews

Header:

Cache-control:no-cache
Connection:close
Content-Encoding:gzip
Content-type:text/html
Server:Web Server
Transfer-encoding:chunked

Meine aktuelle Lösung ist nicht alle die Daten erhalten aufgrund der MaxTries konstant garantiert und ist langsam aufgrund Thread.Sleep ()

private bool MoreDataIsAvailable()
{
    int avail = _socket.Available;
    if (avail == 0 &&
        _contentLength != null && _contentLength == 0)
    {
        int tries = 0;
        while (avail == 0 && tries < MaxTries)
        {
            Thread.Sleep(5);
            _socket.Poll(1000, SelectMode.SelectRead);
            avail = _socket.Available;
            tries++;
            if (avail > 0)
            {
                Console.WriteLine(_socket.Handle + " avail = " + avail + " received = " + _bytes.Length + " && tries = " + tries);
            }
        }
    }
    return avail > 0;
}

Verwendung im Kontext:

private void ReceiveCallback(object sender, SocketAsyncEventArgs e)
{
    if (ConnectionWasClosed(e) || HadSocketError(e))
    {
        _receiveDone.Set();
        return;
    }

    StoreReceivedBytes(e);

    if (AllBytesReceived())
    {
        _receiveDone.Set();
        return;
    }

    if (MoreDataIsExpected() || MoreDataIsAvailable())
    {
        WaitForBytes(e);
    }
    else
    {
        _receiveDone.Set();
    }
}

Beispiel für die Ausgabe:

1436 avail = 3752 received = 1704 && tries = 9
1436 avail = 3752 received = 9208 && tries = 8
1436 avail = 3752 received = 12960 && tries = 9
1436 avail = 3752 received = 20464 && tries = 8
1436 avail = 3752 received = 27968 && tries = 7
1436 avail = 7504 received = 31720 && tries = 1
1436 avail = 3752 received = 39224 && tries = 6

edit:

Nikolai beobachtet, dass die Antworten mit einem Transfer-Encoding: Chunked Header benötigen eine besondere Behandlung, aber ihre Enden können deterministisch nachgewiesen werden.

die chunked Antworten Ohne jedoch gibt es noch andere URLs, die in meiner catch-all-Methode am Ende, Beispiele:

http://www.biomedcentral.com/1471-2105/6/197

Header:

Cache-control:private
Connection:close
Content-Type:text/html
P3P:policyref="/w3c/p3p.xml", CP="NOI DSP COR CURa ADMa DEVa TAIa OUR BUS PHY ONL UNI COM NAV INT DEM PRE"
Server:Microsoft-IIS/5.0
X-Powered-By:ASP.NET

http://slampp.abangadek.com/info/

Header:

Connection:close
Content-Type:text/html
Server:Apache/2.2.8 (Ubuntu) DAV/2 PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.6(2007-09-24) mod_ssl/2.2.8 OpenSSL/0.9.8g
X-Cache:MISS from server03.abangadek.com
X-Powered-By:PHP/5.2.4-2ubuntu5.3

http://video.forbes.com/ embedvideo /? format = frame & height = 515 & width = 336 & mode = render & Netzwerk-Link = 1

Header:

Connection:close
Content-Language:en-US
Content-Type:text/html;charset=ISO-8859-1
Server:Apache-Coyote/1.1

Ich möchte wissen, was ich in diesen Antworten suchen können, die, wie die Transfer-Encoding-Header für die erste URL hat, gibt einen Hinweis die gesamte Antwort auf das Lesen deterministisch, so dass der Aufruf an meine Methode vermieden werden kann.

Answer 1

Von der angegebenen URL scheint es, sind Sie bei HTTP Chunked-Encoding , welche ermöglichen der Server die Antwort vor Gesamtlänge zu beginnen Übertragung bekannt ist, während immer noch die Client ermöglicht, zuverlässig zu Ende der Reaktion zu bestimmen.

Siehe auch RFC 2616, Abschnitt 3.6.1 .