Download bricht nach ca. 2 Minuten ab - ce_download auf Strato PowerPlus L

[darth_saschi]

Hallo zusammen.

Ich habe (mal wieder) ein Problem mit Strato und der Support ist mir (mal wieder) keine Hilfe.

Ich habe zwar ähnliche Threads gefunden, aber noch keine Lösung dazu...

Ich habe das Problem, daß Downloads, die über ce_download gemacht sind, auf meinem Strato-Paket nach exakt 2 Minuten abbrechen.

Ich vermute, daß es irgendein Timeout in den php-Einstellungen ist (max_execution_time? - das steht auf 0, wird auch beim Systemcheck angemeckert).

Mein Problem ist jetzt, daß ich das nicht mal ausprobieren kann: theoretisch kann ichs ja per php.ini ändern, aber auch nur theoretisch, denn sobald ich z.B. eine ins TL-Root lege funktioniert das Frontend gar nicht mehr. info.php zeigt die neue Einstellung richtig an, aber das FE ist platt...

Diese Probleme habe ich auf einem 1und1-Server nicht - aber ich kann nicht so ohne weiteres mit der Domain umziehen...

Könnt Ihr mir helfen?

Vielen Dank.

Der Sascha

[xchs]

Also, "max_execution_time = 0" bedeutet doch normalerweise keine Zeiteinschränkung oder?

[darth_saschi]

Also, "max_execution_time = 0" bedeutet doch normalerweise keine Zeiteinschränkung oder?

Hallo xchs. Danke für die Antwort.

Möglicherweise. Wie gesagt, ich kanns leider nicht ausprobieren, weil, sobald ich eine php.ini ins TL Root lege, das Frontend platt ist. Ich bekomme eine weisse Seite ohne Quellcode...

Eigentlich sollte man das doch eingrenzen können, der Download bricht nach exakt 120 Sekunden ab. Die einzige php-Einstellung, die den Wert "120" hat ist "realpath_cache_ttl". Aber auch an der kann ich nicht drehen.

Strato treibt mich zum Wahnsinn!

Ich hätte auch keine Skrupel zu 1und1 zu wechseln, aber die ganzen IMAP-Mails dann rüber auf die neuen Mailaccounts zu ziehen ist ein Hassel, vor dem ich ziemlichen Respekt habe...

Wenn mir hier jemand helfen könnte dann wäre ich sehr glücklich!

Danke sehr.

Der Sascha

[lucina]

Ich hätte auch keine Skrupel zu 1und1 zu wechseln, aber die ganzen IMAP-Mails dann rüber auf die neuen Mailaccounts zu ziehen ist ein Hassel, vor dem ich ziemlichen Respekt habe...

Ich persönlich hätte nicht die Erwartung, in 1und1 eine qualitativ hochwertige Alternative zu Strato vorzufinden, aber das musst Du ja selbst entscheiden ...

Mit http://www.broobles.com/imapsize/ ist der Umzug von IMAP-Konten übrigens weitgehend schmerzfrei zu bewerkstelligen.

Carolina.

[darth_saschi]

Ich persönlich hätte nicht die Erwartung, in 1und1 eine qualitativ hochwertige Alternative zu Strato vorzufinden, aber das musst Du ja selbst entscheiden ...

Naja, ich habe TL unter einer 1und1 Domain laufen und habe da so gut wie keine Probleme - ganz im Gegensatz zu Strato. Da war das Umschreiben der URLs schon ein echter Kampf...

Mit http://www.broobles.com/imapsize/ ist der Umzug von IMAP-Konten übrigens weitgehend schmerzfrei zu bewerkstelligen.

Ja, das ist doch mal ein feiner Tip! Vielen Dank dafür!

[darth_saschi]

Hallo zusammen.

Ich habe einen Workaround gefunden: Ich bearbeite die Templates von "ce_download" und "ce_downloads" so, daß sie mir keinen Link auf die Downloadseite mit Parametern ausgeben (also downloadseite.html?file=tl_files/file.zip) - sondern direkt den Link auf die Datei - mit onclick="this.blur(); window.open(this.href); return false;" - damit die Dateien nicht das Originalfenster verlassen. Jetzt habe ich zwar nicht mehr den schönen erzwungenen Download-Dialog, aber ich kann somit sehr serverschonend beliebig große Files herunterladen und auch beliebig viele gleichzeitig. So mag ich das. Der User kann dann selbst entscheiden die Dateien zu öffnen oder mit Rechtsklick "Ziel speichern unter" zu speichern.

Das funktioniert prima, aaaber...

...ich arbeite auch gern und viel mit der Extension "downloadarchiv". Hier reicht es leider nicht das Template anzupassen, weil das Template leider nicht den String mit der URL zum File einzeln ausgibt (so wie singleSRC oder multiSRC), sondern das PHP gleich einen String zusammensetzt mit der HTML-Seite + File-URL. Ich konnte das sehr leicht im "ContentDownloadarchiv.php" anpassen, aber das ist ja nicht updatesicher - und außerdem wird das nun so global für alle Downloadarchive gesetzt - per Template könte ich auf unterschiedlichen Seiten auch unterschiedliches verhalten umsetzen.

Frage nun noch: gibt es noch einen Weg das updatesicher hinzubekommen, den ich nicht kenne? In den Configs kann ich soweit ich das sehe nichts einstellen.

Vielen Dank und schöne Grüße.

Der Sascha

[darth_saschi]

...denn unsere liebe Mitarbeiterin willnichgenanntsein hat mit eine feine Regular Expression geschrieben, mit der ich im Template einfach nicht die "href"-Variable nehme, sondern die "href"-Variable, aus der vorher alles inklusive und vor "?file=" rausgeschmissen wird. Damit bleibt nur die URL zum File übrig und damit ists auch updatesicher.

[BastiB]

Hallo darth_saschi,

ich habe ein Problem mit den Downloads: bei über 25MB funktionierts gar nicht und bei direktem Link zur Datei bricht er nach ca 2 Minuten ab. [Ich weiß, diesbezüglich gibt es bereits ein Thread.]

Ich habe nun jedoch herausgefunden, dass durch das Vorgehen via rechte Maustaste und Ziel speichern unter das ganze wunderbar funktioniert.

Was muss ich in ContentDownloadarchiv.php bearbeiten, damit durch einen Klick auf den Link der Browser automatisch den Pfad als "Ziel speichern unter" versteht?

Sorry dass ich hierfür dein Topic missbrauche, aber der Workaround ist ja ähnlich und somit kein neuen Thread wert.

[darth_saschi]

Hallo BastiB.

So wie ich das verstehe kannst Du dieses Verhalten eben nur mit ce_download und Konsorten erzwingen, da hier quasi ein Skript mit einem Parameter aufgerufen wird und nicht die Datei direkt. Mit ebenjenen Skripten habe ich oben beschriebene Probleme, darum habe ich sie "abggestellt" und überlasse es dem User, wie er mit den Links umgeht.

Wenn Du mit Klick auf eine Datei zwingend den "Speichern unter..." Dialog erreichen willst, dann solltest Du die Dateien einfach grundsätzlich zippen - dann geht immer ein Dialog auf.

Der Sascha

[Stofffuchs]

Hallo,

ich habe ein kleines Problem. Meine private Seite habe ich vor einigen Wochen zu tophoster.de (kleinestes Paket) umgezogen. Läuft auch alles prima und schnell. Nun wollte ich Freunden eine 150 MB große Zip Datei zum Download anbieten. Der Link steht in einem Download Element in einem geschützten bereiches des Front End. Die Datei liegt ebenfalls in einem geschützten Verzeichnis.

Ich kann die Datei bei einem 6000 DSL problemlos runterladen. Mich erreichten aber E-Mails von Freunden die meinten der Download bricht ab. Nun habe ich gesucht und durch mehere simultane Downloads die 6 Minuten bis zum Abbruch ermittelt. Ein Test mit einer 7 kb/Sekunde GPRS Verbindung brachte auch bei Dateien mit nur 15 MB selbes Ergebnis.

Kann mir da jemand einen Tipp geben? Da auf einem anderen Webspace mit Contao dieser Fehler nicht auftritt wirds wohl am Hoster liegen? Oder gibts da bei Contao noch was wo ich schauen kann? Verfallszeit einer Session und Autologinzeitraum stehen auf 3600 - also 1 Stunde. Ein Download mit direktem Link (ohne Verzeichnisschutz) funktioniert problemlos.

!EDITH!

Ich habe selbiges gerade mal noch an einer 3. Webseite bei bplaced probiert. Dort tritt selber Fehler bereits nach 4:30 Minuten auf. Die oben erwähnte Seite wo der Fehler nicht auftritt nutzt den SafeModeHack - kann es daran liegen das es geht? Beim Abbruch kommt auch keine Fehlermeldung, der Browser tut so als wäre die Datei fertig geladen. Fehler tritt Browserübergreifend auf. !Edith Ende!

Vielen Dank,

Stofffuchs

Hier mal die PHP Daten:

Directive Local Value
allow_call_time_pass_reference On
allow_url_fopen Off
allow_url_include Off
always_populate_raw_post_data Off
arg_separator.input &
arg_separator.output &
asp_tags Off
auto_append_file no value
auto_globals_jit On
auto_prepend_file no value
browscap no value
default_charset no value
default_mimetype text/html
define_syslog_variables Off
disable_classes no value
disable_functions no value
display_errors On
display_startup_errors Off
doc_root no value
docref_ext no value
docref_root no value
enable_dl On
error_append_string no value
error_log no value
error_prepend_string no value
error_reporting 6135
expose_php Off
extension_dir /usr/local/php5.apxs/lib/php/20060613/
file_uploads On
highlight.bg #FFFFFF
highlight.comment #FF8000
highlight.default #0000BB
highlight.html #000000
highlight.keyword #007700
highlight.string #DD0000
html_errors On
ignore_repeated_errors Off
ignore_repeated_source Off
ignore_user_abort Off
implicit_flush Off
include_path .:/home/www/confixx/html/include:/home/www/confixx/html:/home/www/confixx/html/PEAR
log_errors Off
log_errors_max_len 1024
magic_quotes_gpc Off
magic_quotes_runtime Off
magic_quotes_sybase Off
mail.force_extra_parameters no value
max_execution_time 60
max_file_uploads 20
max_input_nesting_level 64
max_input_time 90
memory_limit 64M
open_basedir /home/www/confixx/:/etc/fastcgi/
output_buffering no value
output_handler no value
post_max_size 8M
precision 14
realpath_cache_size 16K
realpath_cache_ttl 120
register_argc_argv On
register_globals On
register_long_arrays On
report_memleaks On
report_zend_debug On
safe_mode Off
safe_mode_exec_dir /home/www/empty/
safe_mode_gid Off
safe_mode_include_dir /usr/local/php5-fcgi/lib/php/
sendmail_from no value
sendmail_path /usr/sbin/sendmail -t -i
serialize_precision 100
short_open_tag On
SMTP localhost
smtp_port 25
sql.safe_mode Off
track_errors Off
unserialize_callback_func no value
upload_max_filesize 8M
upload_tmp_dir /home/www/confixx/tmp
user_dir no value
variables_order EGPCS
xmlrpc_error_number 0
xmlrpc_errors Off
y2k_compliance On
zend.ze1_compatibility_mode Off

[Stofffuchs]

Da ich ein Update auf Contao 2.10.02 eh vorgesehen hatte habe ich dies heute Morgen gleich mal mit erledigt. Den Fehler hat es erwartungsgemäß nicht behoben, aber anstatt die Downloads einfach zu Beenden bleibt der Download jetzt bei Megabyte X stehen. Lohnt es dafür einen Bug zu melden? Kann jemand den Fehler auf einem eigenen System nachstellen? Welche PHP-Variable könnte da verantwortlich sein?

Stofffuchs

[BugBuster]

Hallo,
da will ich mal was zu sagen:
STRATO: es geht mit eigener php.ini, dazu muss aber die Originale kopiert werden um die Strato Einstellungen nicht zu verlieren.
Die eigene php.ini wird nicht zusätzlich eingelesen sondern stattdessen.

Zum Downloadabbruch: Der Parameter max_execution_time sollte meines Wissens dafür zuständig sein.
Grund ist, dass PHP während des gesamten Downloads mit beteiligt ist, es wird also CPU Zeit (nicht zu verwechseln mit Realtime) dafür gebraucht.
Ist diese quasi aufgebraucht, wird der PHP Prozess beendet.
Sehr große Dateien können daher Probleme machen wenn es zu lange dauert, was natürlich auch von der Datenrate abhängt.
Für solche Zwecke sollte man die Datei direkt verlinken.

[Stofffuchs]

Hallo BB,

die Erklärung mit der execution time leuchtet mir ein. Die steht ja auf 60, der Abbruch erfolgt aber erst bei ca. 600 Sekunden.

Eine direkte verlinkung auf eine geschützte Datei (Contao Verzeichnisschutz) ist nicht möglich, oder? Mit der Erweiterung "tl_fileprotect" habe ich es schon versucht. War aber trotzdem nicht aufrufbar.

Ich werde dann wohl mal den SMH einschalten, auch wenn es nicht nötig ist und damit erneut testen.
Auf einem anderen Webspace (mit SMH zwingend) habe ich genauso geschützte Datein von rund 300 MB - geht problemlos. max_execution_time liegt auch bei 60.

Wie könnte man die Datein noch vor fremden Zugriffen schützen ohne Contao dafür zu nutzen? Kann ich die mit einer eigenen htaccess schützen und dem direkten Link eine Art Zugriffsberechtigung mitgeben? Ich möchte den älteren Herren nicht abverlangen einen htaccess Verzeichnisschutz Benutzernamen und Passwort einzugeben. Das Login auf einer Webseite ist schon grenzwertig.


THX

Stofffuchs

[BugBuster]

die Erklärung mit der execution time leuchtet mir ein. Die steht ja auf 60, der Abbruch erfolgt aber erst bei ca. 600 Sekunden.

Deshalb schrieb ich ja auch das es ein Unterschied ist zw. der realen Zeit und der CPU Zeit die hier definiert wird. Während des Downloads macht die CPU ja noch was anderes z.B.
Es ist daher kein Wunder, dass der Abbruch erst später erfolgt.

Kann man diese setzen, dann erhöhen oder ganz abschalten mit 0, bringt aber die Gefahr mit, wenn ein PHP Prozess hängt, dann für "immer".