Re: Dateinamen beim Herunterladen von Dateien

[daniel _at__ roedding.de (Daniel Roedding)]

Hallo Herr Allers!

Ohne nun Ihren Link konkret ausprobiert zu haben, hier ein paar
allgemeine Anmerkungen zur Thematik:

> Kann es wirklich vorkommen, da=DF beim Herunterladen von Dateien deren
> Name ge=E4ndert wird? Und wenn ja: unter welchen Bedingungen geschieht
> das? Und wo kann man drehen, um das zu verhindern?

Probleme dieser Art sind in verschiedenen Versionen des "Internet Explorer"
bekannt und lassen sich serverseitig leider nicht umgehen.

Während Netscape die vom Server verwendeten Dateinamen "blind übernimmt",
versucht IE offensichtlich, Filenamen und Extension sowie gelieferten
MIME-Type zu korrelieren. Dabei kommen lustige Sachen heraus wie beispiels-
weise:

- serverseitig als "application/octet-stream" gelieferte Dokumente, die
  dummerweise auf ".doc" lauten, gehen direkt nach Word anstatt als Download
  auf die Platte
- serverseitig als "application/irgendwas" gelieferte Dokumente werden
  schon mal als .exe gespeichert
- dann und wann wird der Dateiname völlig ignoriert
- mit Leerzeichen in Download-Filenamen kann IE ohnehin nichts anfangen

Faustregel für die serverseitige Ausgestaltung:

- Der Download-Filename sollte als "local part" in der URL enthalten sein,
  d. h. bei Lieferung aus einem CGI-Binary heraus muß ein Pfad "durch das
  CGI hindurch" gelegt werden. Beispiel:

	/cgi-bin/testme.cgi soll eine Datei "dokument.doc" liefern

  dann muß die Download-URL als

	/cgi-bin/testme.cgi/dokument.doc

  geschrieben werden, damit's wenigstens halbwegs zuverlässig läuft

- Der "Content-Disposition"-Header wird von Netscape nur teilweise und vom
  IE fehlerhaft ausgewertet. Man tut also gut daran, diese Headerzeile,
  die ja auch die Angabe eines clientseitigen Filenamens erlaubt, einfach
  wegzulassen. Durch ihre Verwendung wird der Ärger nur größer...

- Download-Dokumente, die wirklich auf die lokale Platte gehen sollen und
  nicht in irgendein externes Programm, sollten möglichst mit Content-Type
  "application/octet-stream" geliefert werden und idealerweise eine Exten-
  sion tragen, die clientseitig garantiert nicht zu "Verwechslungen" mit
  bekannten applikationsspezifischen Extensionen führen. ".doc" ist also
  keine gute Idee, ".xxx" hingegen ist weniger problemträchtig.

Das größte Problem bei der ganzen Geschichte ist, daß diese Probleme nur
auf Windows-PC's auftauchen, und selbst da kann man nicht von einem
deterministischen Verhalten ausgehen, wenn IE eingesetzt wird. Da Teile der
Verarbeitungsmimik nicht im IE selbst, sondern in unterliegenden DLL's
enthalten sind, kann ein Austausch eines fast beliebigen Programmes auf
einem Windows-Rechner auch zu Verhaltensänderungen im IE führen. Dies
betrifft insbesondere Updates vom Microsoft-Produkten, aber auch Programm-
pakete von Fremdherstellern.

Für Implementatoren von CGI's gilt zusätzlich zu beachten, daß IE bei
CGI-Parametern teilweise Fehlauswertungen von Ausdrücken in URL's vornimmt.

Beispielsweise ist ein Link auf

	/cgi-bin/crashme.cgi?land=Deutschlang&region=Europa

ein völlig korrekter Ausdruck, der aber von IE in bestimmten Konstellationen
"zerfleddert" wird, weil "&reg" enthalten ist, was auch ohne abschließendes
Semikolon zu einem "registrated trademark"-Zeichen wird. Natürlich freut
sich der Server, der mit einer derart verunstalteten URL konfrontiert wird,
darüber nicht besonders und liefert allenfalls suboptimale Ergebnisse...

(BTW: Mit &auml ohne Semikolon passiert das nicht, mit &reg hingegen schon.
      Man kann sich seinen Teil zur Logik des IE'schen HTML-Parsers
      denken...)

Viele Grüße,
Daniel Rödding



-- 
Daniel Roedding                                       phone: +49 5252 9838 0
daniel _at__ roedding.de                                      fax: +49 5252 9838 20