Warum Rebol Raw Http Head Request, um Remote-Dateigröße sehr langsam im Vergleich zu Info zu erhalten? Funktion

Question

Antwort mit Info? ist sehr schnell:

i: info? http://cdimage.ubuntu.com/daily/current/natty-alternate-i386.iso 
i/size 

Mit http-Kopf-Anfrage dauert es vielleicht 10 mal mehr Zeit, warum?

port: open tcp://cdimage.ubuntu.com:80 
insert port "HEAD /daily/current/natty-alternate-i386.iso HTTP/1.1 ^/" 
insert port "Host: cdimage.ubuntu.com ^/^/" 
out: copy "" 
while [data: copy port][append out data] 
block: parse out rejoin [": " newline] 
select block "Content-Length" 

Answer 1

die Port-Modi sind in diesem Fall verantwortlich. Sie verwenden gepufferte E/A mit dem Wartemodus (der standardmäßig aktiviert ist).

in http, der Client ist verantwortlich für das Schließen des Ports, wenn Sie alle Server-Bytes gelesen haben.

Da Sie tcp grundsätzlich direkt verwenden und den Insert-Port verwenden, müssen Sie auch das Ende der Anforderung erkennen und den Port schließen, wenn genügend Bytes angekommen sind. Dies kann nur in/line oder/no-wait durchgeführt werden, wenn Low-Level-Tcp-Spaß gemacht wird.

Etwas, das gelesen und Info? für dich tun.

während [Daten: copy port] [append out data]

nicht abschließt, bis eine Zeitüberschreitung auftritt (die in REBOL standardmäßig 30 Sekunden ist).

auch, scheint Ihre Anfrage fehlerhaft zu sein ...

try this:

port: open/lines tcp://cdimage.ubuntu.com:80 
insert port {HEAD /daily/current/natty-alternate-i386.iso HTTP/1.0 
Accept: */* 
Connection: close 
User-Agent: REBOL View 2.7.7.3.1 
Host: cdimage.ubuntu.com 
} 
out: form copy port 
block: parse out none ;rejoin [": ^/"] 
probe select block "Content-Length:" 

hier, dass es scheint, das Hinzufügen/Linien, die die Wartezeit verhindern. es hängt wahrscheinlich damit zusammen, wie das http-Schema den Leitungsmodus bei open handhabt.

suchen Sie nach REBOL-Port-Modi in der Dokumentation und im Internet ist es überall gut erklärt.

Wenn Sie trace/net eingeschaltet hätten, hätten Sie erkannt, dass alle Pakete empfangen wurden und der Interpreter gerade noch wartet. Übrigens hat Ihr Code in meinen Tests tatsächlich einen Fehler von 400 zurückgegeben.