HTTP oder FTP für Downloads?

[BlueStarHH]

Hi,

ein Kollege von mir bietet auf seiner Internetseite ein 5 MB großes Freeware-Tool an. In letzter Zeit gibt es immer mehr Beschwerden, dass ein vollständiger Download nicht möglich ist. Der Hoster hat zu ihm gesagt: Er soll es nicht per HTPP anbieten, sondern per FTP-Download. Der Kollege hat mich nun gefragt, ob FTP wirklich Vorteile (immer vollständiger Download?) bringt und was für Nachteile das haben kann. Da ich mich damit aber auch nicht auskenne, stelle ich die Frage hier mal zu Diskussion. Mir ist nur aufgefallen, dass so gut wie überall, wo man Sofware laden kann, HTTP genutzt wird. Das muss ja auch einen Grund haben. Kann jeder Browser mit Boardmitteln heute FTP downloaden? Auch wenn man hinter einer Firewall oder NAT sitzt?

Danke

[generic]

HTTP!

Hat folgende Vorteile:
* geht besser durch Firewalls da nur ein Port benötigt wird (80 oder 443)
* kann auch durch NAT genutzt werden (ohne wie bei FTP auf Passiv zu wechseln).
* der Download kann von Providern und in Firmennetzwerken (in Proxies) gecachet werden
* unterstützt im Normalfall Teilweisedownloads (HTTP-Range) und Wiederaufnahme von Downloads.
* es können einfach CDN's wie z.B. Akamai genutzt werden

HTTP-Downloadmanager sind bei Benutzer oft installiert ober bereits im Browser integriert.

Nachteil:
* der HTTP Header wird pro Stream übertragen und fügt bis ca. 200 Byte an Daten hinzu (pro Stream)


Das mit den vollständigen Downloads klingt nach einen instabilen Server/Betreiber/Netzwerk.
Ich hab mit Sutd/Bomac keine derartigen Probleme.

[himitsu]

Zitat von BlueStarHH:

Mir ist nur aufgefallen, dass so gut wie überall, wo man Sofware laden kann, HTTP genutzt wird.

Das liegt nur daran, weil es einfach ist.

HTTP ist bei Webseiten nunmal schon offen, um die Webseite anzuzeigen.
Bei FTP müßte man erst einen Gastzugang einrichten, welcher ohne Passwort, geheimen Nutzernamen und vorallem mit Nur-Lese-Rechten versehen ist.


FTP scheint (vermutlich außerhalb der spezifikation und nicht bei allen FTP-Servern auch Teilweise Down-/Uploads zu unterstüzen ... jedenfalls glaube ich mich zu erinnern, dß der Filezilla sowas kann.


Wird die Datei würklich nur vom HTTP-Server rausgegeben, oder arbeitet da im Hintergrund z.B. noch PHP, CGI oder sowas, welches den Dateizugriff überwacht?
Da kann z.b. ein Timeout bei der Scriptausfühung zuschlagen, wenn der Download langsam ist.
Und was vorallem PHP-Scripte gern mal vergessen, also z.B. die Dateigröße im Header anzugeben, da kann bei kurzen Downloadverzögerungen der Browser schnell mal denken die Datei ist fertig, da er dann auf das Streamende wartet, anstatt zu warten, bis genügend Bytes eingetroffen sind.



Ach ja, FTP "lesen" kann eigentlich nahezu jeder Browser. (der FF kann schreiben nur via Plugin und der IE konnte früher auch mal von sich aus schreiben, aber das hat der irgendwann verlernt )

[BlueStarHH]

Zitat von himitsu:

Wird die Datei würklich nur vom HTTP-Server rausgegeben, oder arbeitet da im Hintergrund z.B. noch PHP, CGI oder sowas, welches den Dateizugriff überwacht?
Da kann z.b. ein Timeout bei der Scriptausfühung zuschlagen, wenn der Download langsam ist.
Und was vorallem PHP-Scripte gern mal vergessen, also z.B. die Dateigröße im Header anzugeben, da kann bei kurzen Downloadverzögerungen der Browser schnell mal denken die Datei ist fertig, da er dann auf das Streamende wartet, anstatt zu warten, bis genügend Bytes eingetroffen sind.

Es wird ein simples Pearl-CGI-Script verwendet, dass den Download zählt und ihn dann wie folgt ausführt:

Code:

print "Location: $DL\n\n";

$DL ist die Download-URL. Also müsste man Deiner Aussage nach es so abändern und die Probleme wären weg:

Code:

print "Content-Type: application/octet-stream\n";
print "Content-Length: ".$fileSize."\n";
print "Location: $DL\n\n";

Auf die schnelle gegoogelt. Kann man dann noch Location nutzen?

[himitsu]

Location ist doch eine Umleitung (wenn ich mich jetzt richtig erinnere), dann dürfte der Browser nach diesem CGI-Sctipt dann die Datei anhand der übergebenen DL-Adresse neu beim Server anfordern und dann hoffentlich direkt vom HTTP-Server abrufen.

Eventuell erkennt man im Log des HTTP-Servers, warum die Downloads abbrechen?





In PHP sieht man oftmals nur sowas (sehr oft ohne Content-Length, Content-Disposition usw.),

Code:

header("Content-Type: $type");
header("Content-Disposition: attachment; filename=\"$file\"");
readfile($dir.$file);

wo die "richtige" Dateiadresse nicht verraten wird (bei dem Location könnte man die eigentlich Datei-URL auslesen und dann an dem Downloadscript vorbei die Datei direkt laden. Also wenn man dann diese URL an Andere weitergibt, dann würden diese nicht mehr mitgezählt.

Hier bleibt das PHP-Script so lange aktiv, bis der Download fertig ist und die Verbindung getrennt wurde.
Wenn der Downlod nun zu lange dauert, dann kann ein Timeout im PHP-Server das Script und damit den Download abbrechen.


Wenn im HTTP-Log nichts zu finden ist...
Zumindestens dieses PHP-Script kann man so erweitern, daß es mitlogt, ob/wann die Verbindung clientseitig getrennt wurde, bzw. ob das Scripttimeout oder eine andere Exception zugeschlagen hat.
Gent eventuell geht das auch mit CGI, wenn man dort die Datei ebenfalls direkt ausliefert, aber mit CGI hab ich noch nie was gemacht.

[BUG]

Zitat von generic:

* unterstützt im Normalfall Teilweisedownloads (HTTP-Range) und Wiederaufnahme von Downloads.
...
Das mit den vollständigen Downloads klingt nach einen instabilen Server/Betreiber/Netzwerk.

Vermutlich unterstützt der Hoster keine Wiederaufnahme und bricht ab und zu lange Verbindungen ab. Das macht sich bei Downloads schlecht
Man könnte versuchen, das mit einem Downloadscript zu umgehen, dass mit byte serving unterstützt

Vermutlich ist das irgendein Shared-Hoster, der eh nicht "so große" Dateien bereitstellen möchte.
Wenn man nicht den Hoster komplett wechseln will, könnte man versuchen, wenigstens den Download bei einem vernünftigen Anbieter unterzubringen (z.B. Amazon S3, geht in Maßen sogar kostenlos).

[himitsu]

Stimmt, das mit den Free-Hostern, die ein Limit bei den Dateigrößen haben, gibt es auch, wobei ich da dachte die sperren schon das Hochladen solcher Dateien und nicht erst den download.

Aber wenn ich es mir so überlegen, dann könnte man ja per PHP/CGI/... dieses Dateilimit einfach umgehen, indem man die Datei in Stücken hochläd und erst beim Download zusammensetzt.


[add]
Im Notfall kann er die Datei auch erstmal bei einem externen Filehoster hochladen und den Download dahin verlinken, wenn das Problem wirklich sein Hoster ist.
(aber bitte nix, wo man nur extrem langsam downloaden kann, vorher noch ewig Wartezeiten hat, wo man mit nicht erkennbaren Captchas konftontiert wird, oder was nette IP-Sperren hat, die z.B. via UMTS gleich alle in der selben Funkzelle aussperrt)

Wenn ich mich z.B. bei Funpic umseh, dann hat dort der Freespace auch zufällig ein 5 MB-Limit für Dateien und ich glaub ich zu erinnern, daß ich dennoch was Größeres hochladen konnte.

[generic]

Zitat von himitsu:

In PHP sieht man oftmals nur sowas (sehr oft ohne Content-Length, Content-Disposition usw.),

Code:

header("Content-Type: $type");
header("Content-Disposition: attachment; filename=\"$file\"");
readfile($dir.$file);

Dieser PHP Code ist leider einer der meist genutzten. Doch leider gehen hier viele Funktionen wir HTTP-Range usw. nicht. Die Browser, wie du schon schreibst, haben Aufgrund der fehlenden Header auch so ihre Probleme.

Ich würde die Datei auf jedenfalls NICHT durch ein Script ausliefern lassen, es sein denn man weiß zu 100% was man da tut.
Der Webserver kann das meist besser und hat auch die passenden Unterstützungen wie Range etc.