nicht angemeldet
Unterbrochene HTTP-Downloads fortsetzen
Hallo,
wieso lassen sich eigentlich, unterbrochene HTTP-Downloads nicht fortsetzen? Beispielsweise, wenn die Internet-Verbindung unterbrochen wird, und man sich neu einwählen muss. HTTP basiert doch auf TCP, und TCP beinhaltet Fehlererkennung und Korrektur.
Gruß
-
Hi,
wieso lassen sich eigentlich, unterbrochene HTTP-Downloads nicht fortsetzen? [....]
ich würd jetzt mal behaupten weil du ja nach Neueinwahl eine neue IP zugewiesen bekommst, woher soll dann der Server wissen dass du bereits angefangen hast eine Datei runterzuladen (unter einer anderen IP), er "kennt" dich ja noch nicht.
gruß simk
-
Hi,
ich würd jetzt mal behaupten weil du ja nach Neueinwahl eine neue IP zugewiesen bekommst, woher soll dann der Server wissen dass du bereits angefangen hast eine Datei runterzuladen (unter einer anderen IP), er "kennt" dich ja noch nicht.
es gibt in HTTP keine Wiedererkennung.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
-
-
Hi,
wieso lassen sich eigentlich, unterbrochene HTTP-Downloads nicht fortsetzen? Beispielsweise, wenn die Internet-Verbindung unterbrochen wird, und man sich neu einwählen muss. HTTP basiert doch auf TCP, und TCP beinhaltet Fehlererkennung und Korrektur.
ja, aber HTTP ist zustands- und verbindungslos. Bricht die Verbindung ab, hat sie nie bestanden.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
ja, aber HTTP ist zustands- und verbindungslos. Bricht die Verbindung ab, hat sie nie bestanden.
Zwar korrekt, aber nicht der volle Grund, warum eine erneute Verbindungsaufnahme an der gleichen Stelle nicht möglich ist. Dieser besteht nämlich darin, dass der Server den Chunked Transfer, wie er in Absatz 3.6.1 in RFC 2616 definiert wird, nicht unterstützt. Damit wäre es nämlich möglich, einen beliebigen Chunk bestimmter Größe vom Server anzufordern und den Download somit fortzusetzen.
Gruß, LX
--
X-Self-Code: sh:( fo:) ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: Unusual
X-Please-Search-Archive-First: Absolutely Yes -
(Hallo|Hi(ho)|Nabend) Cheatah,
(...) HTTP basiert doch auf TCP, (...)
ja, aber HTTP ist zustands- und verbindungslos. (...)
Das erinnert mich an einen lustigen Benutzerkommentar im Coding-Horror-Blog:
Let's see here...
IP = stateless
TCP/IP = built on IP, stateful
HTTP = built on TCP, stateless
WebApp = build on HTTP, stateful...what's wrong with this picture? (...)
Captain Obvious on April 16, 2008 06:36 AMMffG
EisFuX
-
-
Hi,
wieso lassen sich eigentlich, unterbrochene HTTP-Downloads nicht fortsetzen?
Wie kommst du darauf, dass das nicht ginge?
Server und Client muessen lediglich Range Requests unterstuetzen.
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“ -
Moin!
wieso lassen sich eigentlich, unterbrochene HTTP-Downloads nicht fortsetzen?
Das funktioniert, allerdings nur, wenn der Client und der Server es erlauben, beim (erneuten) Download den gewünschten Dateibereich anzugeben - denn ohne diese Angabe wüßte der Server ja nicht, dass er den ersten Teil der Datei nicht nochmal senden muss, wenn diese angefordert wird.
Das funktioniert aber dann nicht, wenn der Server die Datei beispielsweise über ein Downloadscript ausliefert, welches diese Range-Requests nicht beachtet.
Beispielsweise, wenn die Internet-Verbindung unterbrochen wird, und man sich neu einwählen muss. HTTP basiert doch auf TCP, und TCP beinhaltet Fehlererkennung und Korrektur.
TCP erkennt ja auch zuverlässig, dass deine Internetverbindung unterbrochen wurde, der Server erkennt exakt, dass die Datenpakete dich nicht mehr erreichen, und ein weiteres Senden somit sinnlos ist. Zu mehr ist TCP aber nicht fähig.
- Sven Rautenberg
-
Tach,
HTTP basiert doch auf TCP
nein, wir setzen es zwar quasi ausschließlich unter TCP ein, allerdings könnten wir auch problemlos andere Transportprotokolle nutzen:
"On the Internet, HTTP communication generally takes place over TCP/IP connections. The default port is TCP 80 [15], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used, and the mapping of the HTTP/1.0 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification." - RFC 1945
HTTP geht nur davon aus, dass die Verbindung gesichert abläuft, schließt also z.B. UDP als Protokoll eher aus, eine Implementierung über SCTP oder SPX wäre dagegen kein Problem.
mfg
Woodfighter