download über CGI script

[Frank]

Moin leutz,

mein Problem ist volgendes: Ich möchte Dateien auf einem Webserver zum Download bereitstellen. Diese Dateien sollen aber nicht klassisch heruntergeladen werden, sonder über ein CGI (Perl) script.
Im prinzip funktioniert es auch, als MIME Type habe ich "multipart/octet-stream" festgelegt und so kommen die Daten auch richtig beim Client an.
Jedoch wird der Dateiname nicht richtig übertragen. Als Dateiname wird immer der Name des scriptes angenommen. Ich wüsste jetzt gerne, was ich in den MIME header schreiben muss, damit der Dateiname richtig übertragen wird.

vielen Dank schon einmal im vorraus.

by

[Klasu Mock]

Hallo,

Jedoch wird der Dateiname nicht richtig übertragen. [...]

Eigentlich gehört im HTTP-Responseheader die 'Content-Disposition' definiert.

mit dem CGI-Modul kannst Du das so erledigen:

print $query->header(-type=>'application/octet-stream',
                             -attachment=>'filename.ext'
                             );

Grüße
  Klaus

[roro]

Moin :)

hier noch eine andere Variante die Sinn macht wenn
mehrere Dateien angeboten werden:

-über Checkboxen kann der Besucher die Dateien auswählen
welche er downloaden möchte

-das Script erzeugt damit eine download.tar (Archive::Tar)
-dann macht das Script einen redirekt auf die download.tar

Die meisten Browser wissen mit einer TAR nix anzufangen und
bieten die Datei zum Download an.

Script steht in meinem Downloadbereich zur Verfügung :)

Rolf

[Michael Schröpl]

Hallo Rolf,

-das Script erzeugt damit eine download.tar (Archive::Tar)
-dann macht das Script einen redirekt auf die download.tar

^^^^^^^^^^^^
Synchronisation bei simultanen Anforderungen? (PID?)

Viele Grüße
      Michael

[roro]

Hallo Rolf,

-das Script erzeugt damit eine download.tar (Archive::Tar)
-dann macht das Script einen redirekt auf die download.tar
                                                 ^^^^^^^^^^^^
Synchronisation bei simultanen Anforderungen? (PID?)

Hi Michael, ja ja :)  Sollte ich machen ! Hab ich aber
nicht weil: An der Stelle isses mir wurscht! Wenn einer
das Tar vom Anderen bekommt (was beim derzeitigen Traffic
wohl eher die Ausnahme sein sollte...) muss er es halt
nochmal versuchen *g

Achja, das Script dazu kost nix und jeder kann damit
machen was er will - also auch verbessern.

Viele Grüße, Rolf

[Michael Schröpl]

Hallo Rolf,

-dann macht das Script einen redirekt auf die download.tar
                                                 ^^^^^^^^^^^^
Synchronisation bei simultanen Anforderungen? (PID?)
Hi Michael, ja ja :)  Sollte ich machen ! Hab ich aber
nicht weil: An der Stelle isses mir wurscht!

Pfui! $ENV{'PID'} in den Pfadnamen des Archivs einzufügen kann doch
nicht sooo schwierig sein ... tststs ... ;-)

Wenn einer das Tar vom Anderen bekommt (was beim derzeitigen Traffic
wohl eher die Ausnahme sein sollte...) muss er es halt nochmal
versuchen *g

Bei Dir würde ich kein Bankkonto einrichten wollen. ;-)

Viele Grüße
      Michael

[roro]

Hi Michael;-)

Synchronisation bei simultanen Anforderungen? (PID?)
Hi Michael, ja ja :)  Sollte ich machen ! Hab ich aber
nicht weil: An der Stelle isses mir wurscht!

Pfui! $ENV{'PID'} in den Pfadnamen des Archivs einzufügen kann doch
nicht sooo schwierig sein ... tststs ... ;-)

Und wer soll den Müll am Ende löschen wenn das Script vorbei ist?

Wenn einer das Tar vom Anderen bekommt (was beim derzeitigen Traffic
wohl eher die Ausnahme sein sollte...) muss er es halt nochmal
versuchen *g

Bei Dir würde ich kein Bankkonto einrichten wollen. ;-)

Warum nicht ? Vielleicht hast du dann mit deinem Konto mehr Glück und kriegts laufend irgendwelche Überweisungen hihi.

Viele Grüße
      Michael

Too!

Rolf

[Michael Schröpl]

Hallo Rolf,

Pfui! $ENV{'PID'} in den Pfadnamen des Archivs einzufügen kann doch
nicht sooo schwierig sein ... tststs ... ;-)
Und wer soll den Müll am Ende löschen wenn das Script vorbei ist?

Derselbe, der es bisher auch schon tut: Der nächste Downloader.

(directory scan, stat, modification date; alles löschen, was signifikant
 älter als http server timeout - sagen wir mal: Mindestens einen Tag alt
 oder so. Mehr als schiefgehen kann löschen nicht, also keine Synchroni-
 sation dafür.)

Viele Grüße
      Michael

[roro]

hi Michael,

Pfui! $ENV{'PID'} in den Pfadnamen des Archivs einzufügen kann doch
nicht sooo schwierig sein ... tststs ... ;-)
Und wer soll den Müll am Ende löschen wenn das Script vorbei ist?

Derselbe, der es bisher auch schon tut: Der nächste Downloader.

(directory scan, stat, modification date; alles löschen, was signifikant
älter als http server timeout - sagen wir mal: Mindestens einen Tag alt
oder so. Mehr als schiefgehen kann löschen nicht, also keine Synchroni-
sation dafür.)

Jow! so gänge es. Ergo: Script bleibt so wie's ist.

Schönes Wochendende, Grüße aus Linkenheim(Baden); Rolf

PS: Disclaimer :-)

Wer bei mir ein Download zusammenstellt, downloadet und dann der Meinung ist dass er eine TAR bekommen hat wo ein anderer zusammengestellt hat möge sich bitte bei mir melden !

[Klaus Mock]

Grüß euch,

Ich habe gerade die Diskussion zwischen euch verfolgt. Dazu ist  mir nur eins eingefallen:
Warum einfach, wenns kompliziert geht?

Wenn ich schon das Script am laufen habe,das ganze schom mal mit Archive::Tar zusammengepoppelt habe, es also schon im Memory herumgammelt, warum dann extra in eine Datei schreiben und dann darauf verweisen?
Schick es einfach gleich an den Browser.

[...]
$tar->add_files(@den_ganzen_ausgesuchten_kram);
print $query->header(-type=>'application/x-tar',
                             -attachment=>'download.tar'
                             );

print $tar->data();

[...]

Dann hast Du gleich den Vorteil, daß kein neuer Request entseht und hinterher zusammenräumen ist auch nicht notwendig.
UNt streiten braucht auch keiner.

Grüße
  Klaus

[roro]

moin, moin,

wird sofort getestet, gute Idee Klaus !

Viele Grüße, Rolf

[Calocybe]

Hi!

Die meisten Browser wissen mit einer TAR nix anzufangen und
bieten die Datei zum Download an.

Was hat das mit der Dateiendung zu tun? Wenn man weitgehend sicher gehen will, dass eine Datei wirklich zum Download angeboten wird, verwendet man normalerweise den Content-type application/octet-stream oder x/unknown-content-type. Koennte allerdings sein, dass da der IE wieder querschiesst und ploetzlich die Datei als Seite anzeigt, weil er irgendwo ein paar HTML-Aehnliche Zeichenfolgen gefunden hat. Aber naja, man kann halt nicht auf jeden verbuggten Nischenbrowser Ruecksicht nehmen. ;-)

Uebrigens kann WinZip z.B. auch TARs oeffnen, von daher sollte das in den vielen Browsern sehr wohl bekannt sein.

So long

[Andreas Bierhals]

Moin,

Jedoch wird der Dateiname nicht richtig übertragen. Als Dateiname wird immer der Name des scriptes angenommen. Ich wüsste jetzt gerne, was ich in den MIME header schreiben muss, damit der Dateiname richtig übertragen wird.

man kann das Problem lösen, indem man in das Formular folgendes schreibt:

statt: <form action="/cgi-bin/download.cgi" ...>

schreibt man

<form action="/cgi-bin/download.cgi/filename.ext" ...>

auch wenn es eine Datei "filename.ext" auf dem Server gar nicht gibt.
Der Witz ist, daß der Server die Pfadangabe bereits bei der
vorhandenen Datei ../download.cgi abschneidet und den Rest
als "path_info" übergibt. Die meisten Browser generieren daraus
automatisch einen korrekten Download-Dateinamen.

Viele Grüße

Andreas