PDFs immer noch mit Content-Disposition-Header ausliefern?

[Christoph Schneegans]

Hallo allerseits

Fr�her� habe ich PDF-Dokumente gerne mit einem HTTP-Header

Content-Disposition: attachment; filename=foo.pdf

ausgeliefert. Das hatte gleich mehrere Vorteile:

� Die Anzeige erfolgte nicht "inline" im Browser, sondern in einem
eigenen Proze�, was typischerweise die Stabilit�t verbesserte.
� Auch ein unbedarfter Anwender konnte das PDF-Dokument bequem
abspeichern.

Nun gibt es mit Chrome und Firefox aber mittlerweile zwei Browser,
die ihren eigenen PDF-Viewer mitbringen, und hier k�nnte sich ein
Content-Disposition-Header sehr wohl nachteilig auswirken.
Sowohl Chrome als auch Firefox wollen ein PDF-Dokument mit Content-
Disposition-Header vorzugsweise abspeichern; um es stattdessen
anzuzeigen, sind in jedem Fall mehrere Mausklicks n�tig.

Ist �berhaupt kein eigenst�ndiger PDF-Viewer installiert, kann ein
PDF-Dokument, das _ohne_ Content-Disposition-Header ausgeliefert
wird, in Chrome und Firefox dennoch unmittelbar angezeigt werden.
Bei einem PDF-Dokument hingegen, das _mit_ Content-Disposition-
Header ausgeliefert wird, braucht es einige Verrenkungen, denn weder
Chrome noch Firefox scheinen sich als PDF-Viewer im Betriebssytem zu
registrieren.

Auch f�hlen sich die PDF-Viewer von Chrome und Firefox in der
Bedienung gut an, und die Performance ist nach meinem Eindruck auch
ordentlich, jedenfalls viel besser als beim Adobe-Plugin.

Ich �berlege also, ob man weiterhin den Content-Disposition-Header
f�r PDF-Dokumente verwenden sollte. Wie handhabt ihr das?

Wer ausprobieren m�chte, wie sich die verschiedenen Browser
verhalten, kann das gerne anhand von
<http://schneegans.de/temp/content-disposition/> tun.

--
�Ich werde zu diesen Personen geh�ren, die ab 2013 mit geringem
Aufwand sich gegen den �ffentlich-rechtlichen Rundfunk stellen
werden.� � <http://www.online-boykott.de/de/klagen-statt-zahlen>

[Thomas 'PointedEars' Lahn]

Christoph Schneegans wrote:

> [Built-in PDF-Viewer in modernen Browsern]
> Ich überlege also, ob man weiterhin den Content-Disposition-Header
> für PDF-Dokumente verwenden sollte. Wie handhabt ihr das?

Ich habe es schon immer für das Beste gehalten, Ressourcen mit dem passenden
Content-Type und ohne Content-Disposition anzubieten – es sei denn, es soll
*auf jeden Fall* ein Dateidownload stattfinden, dann application/octet-
stream. Somit können dann notfalls zwei Links für eine solche Ressource
angeboten werden: einer zum Betrachten (sofern Viewer installiert) und einer
für den Dateidownload. Der Benutzer wird wissen, welchen Link er verwenden
will, und wenn er es nicht weiss, ist es ihm wahrscheinlich egal.

> Wer ausprobieren möchte, wie sich die verschiedenen Browser

> verhalten, kann das gerne anhand von
> <http://schneegans.de/temp/content-disposition/> tun.

Content-Disposition machte in älteren IEs Probleme, daher habe ich es IIRC
seit jeher gemieden.


PointedEars
--
Lass es mich so ausdrücken: Eigentlich werde ich keine Zeit haben, aber die
fürs Usenet übliche nehme ich mir. Nähme ich mir noch zusätzlich was vor,
würde ich womöglich das tun, um nicht das, das ich tun sollte, tun zu
müssen.
(Christoph Päper in <darw/> <avl5ul$30fp$1...@ariadne.rz.tu-clausthal.de>)

[Frank Müller]

Christoph Schneegans schrieb:
> Hallo allerseits
>
> Früher™ habe ich PDF-Dokumente gerne mit einem HTTP-Header

>
> Content-Disposition: attachment; filename=foo.pdf
>
> ausgeliefert. Das hatte gleich mehrere Vorteile:
>

> • Die Anzeige erfolgte nicht "inline" im Browser, sondern in einem
> eigenen Prozeß, was typischerweise die Stabilität verbesserte.
> • Auch ein unbedarfter Anwender konnte das PDF-Dokument bequem
> abspeichern.

Das ist aber seit einigen Acrobat-Readern überholt, also
abspeichern geht jetzt auch, sogar im Browser-Plugin.

> Nun gibt es mit Chrome und Firefox aber mittlerweile zwei Browser,

> die ihren eigenen PDF-Viewer mitbringen, und hier könnte sich ein

> Content-Disposition-Header sehr wohl nachteilig auswirken.

Chrome habe ich noch nicht probiert, aber im Firefox der Viewer
ist nur für ganz einfache PDF brauchbar, sobald eine Schriftart
in den PDF ist die nicht installiert ist macht der ganz komische
Dinge.

> Auch fühlen sich die PDF-Viewer von Chrome und Firefox in der

> Bedienung gut an, und die Performance ist nach meinem Eindruck auch
> ordentlich, jedenfalls viel besser als beim Adobe-Plugin.

Es geht schneller, aber das ist auch der einzige Vorteil...

> Ich überlege also, ob man weiterhin den Content-Disposition-Header
> für PDF-Dokumente verwenden sollte. Wie handhabt ihr das?

Einfach verlinken, ohne irgendwas anzugeben. Der Browser sucht
sich dann das passende schon raus. Ich finde es jedenfalls immer
lästig, wenn ich nur mal sehen will was da steht und muß deshalb
die ganze PDF erst downloaden um sie mir anzusehen.

Frank

[Matthias Würfl]

Am 18.04.2013 10:14, schrieb Frank Müller:

> Einfach verlinken, ohne irgendwas anzugeben.

Keine http-Header mitsenden? Hä?

> Der Browser sucht
> sich dann das passende schon raus.

Woher weiß der Browser, was das passende ist?

> Ich finde es jedenfalls immer
> lästig, wenn ich nur mal sehen will was da steht und muß deshalb
> die ganze PDF erst downloaden um sie mir anzusehen.

Wie sieht die Alternative aus? Wie kannst Du sie sehen, ohne sie vorher
heruntergeladen zu haben?

Grüße, Matthias

[Thomas 'PointedEars' Lahn]

Matthias Würfl wrote:

> Am 18.04.2013 10:14, schrieb Frank Müller:
>> Einfach verlinken, ohne irgendwas anzugeben.
>
> Keine http-Header mitsenden? Hä?

Er meint das Standardverhalten von Webservern: Dateisuffix angucken,
Response mit passendem Content-Type ohne Content-Disposition senden.

Dabei ist ihm aber nicht klar, dass PDFs manchmal auch generiert werden, zum
Beispiel mit PHP. Ohne Content-Disposition (womit man einen Dateinamen zum
Speichern vorgeben kann) hilft hier Content Negotiation oder URL-Rewrite,
indem dem Browser ein .pdf vorgegaukelt wird, hinter dem sich z. B. ein
solches PHP-Script verbirgt.

>> Der Browser sucht
>> sich dann das passende schon raus.
>
> Woher weiß der Browser, was das passende ist?

Das hat ihm der Benutzer vorher gesagt. Wenn nicht, ist es dem Benutzer
egal, also sollte es auch dem Autor egal sein.

>> Ich finde es jedenfalls immer
>> lästig, wenn ich nur mal sehen will was da steht und muß deshalb
>> die ganze PDF erst downloaden um sie mir anzusehen.
>
> Wie sieht die Alternative aus? Wie kannst Du sie sehen, ohne sie vorher
> heruntergeladen zu haben?

Er meint den Dateidownload, dessen Ziel ein benutzerdefiniertes Verzeichnis
ist.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Christoph Schneegans]

Thomas 'PointedEars' Lahn schrieb:

> Dabei ist ihm aber nicht klar, dass PDFs manchmal auch generiert werden, zum
> Beispiel mit PHP. Ohne Content-Disposition (womit man einen Dateinamen zum
> Speichern vorgeben kann) hilft hier Content Negotiation oder URL-Rewrite,
> indem dem Browser ein .pdf vorgegaukelt wird, hinter dem sich z. B. ein
> solches PHP-Script verbirgt.

Wie kommst du denn jetzt darauf? Nicht ".pdf" in der URL ist relevant,
sondern "Content-Type: application/pdf", und so einen Header kann ein
PHP-Skript genauso erzeugen wie der Webserver.

Andernfalls würden meine Beispiele ja auch gar nicht funktionieren, vgl.
<http://web-sniffer.net/?url=http://schneegans.de/temp/content-disposition/?cd=true>
bzw.
<http://web-sniffer.net/?url=http://schneegans.de/temp/content-disposition/?cd=false>.

--
„Ich werde zu diesen Personen gehören, die ab 2013 mit geringem
Aufwand sich gegen den öffentlich-rechtlichen Rundfunk stellen
werden.“ — <http://www.online-boykott.de/de/klagen-statt-zahlen>

[Frank Müller]

Matthias W�rfl schrieb:

> Am 18.04.2013 10:14, schrieb Frank M�ller:
>> Der Browser sucht
>> sich dann das passende schon raus.
>

> Woher wei� der Browser, was das passende ist?

Ich nehme mal an der geht nach der Datei-Endung.

>> Ich finde es jedenfalls immer

>> l�stig, wenn ich nur mal sehen will was da steht und mu� deshalb

>> die ganze PDF erst downloaden um sie mir anzusehen.
>
> Wie sieht die Alternative aus? Wie kannst Du sie sehen, ohne sie
> vorher heruntergeladen zu haben?

Gr��eren PDF-Dateien zeigt mir das Adobe-Acrobat-Plugin
die ersten Seiten w�hrend die Datei noch l�dt.

Frank

[Arno Welzel]

Thomas 'PointedEars' Lahn, 2013-04-18 11:22:

> Matthias Würfl wrote:
>
>> Am 18.04.2013 10:14, schrieb Frank Müller:
>>> Einfach verlinken, ohne irgendwas anzugeben.
>>
>> Keine http-Header mitsenden? Hä?
>
> Er meint das Standardverhalten von Webservern: Dateisuffix angucken,
> Response mit passendem Content-Type ohne Content-Disposition senden.
>
> Dabei ist ihm aber nicht klar, dass PDFs manchmal auch generiert werden, zum
> Beispiel mit PHP. Ohne Content-Disposition (womit man einen Dateinamen zum
> Speichern vorgeben kann) hilft hier Content Negotiation oder URL-Rewrite,
> indem dem Browser ein .pdf vorgegaukelt wird, hinter dem sich z. B. ein
> solches PHP-Script verbirgt.

Ja - sofern der Browser so kaputt ist, dass er den Content-Type nicht
beachtet, den man auch problemlos mit PHP setzen kann.

Gibt es noch halbwegs aktuelle Browser, die den Content-Type anhand der
vermeintlichen "Dateiendung" in der URL "erraten", obwohl er im Header
eindeutig übermittelt wird?


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[Thomas 'PointedEars' Lahn]

Christoph Schneegans wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Dabei ist ihm aber nicht klar, dass PDFs manchmal auch generiert werden,
>> zum Beispiel mit PHP. Ohne Content-Disposition (womit man einen

^^^^^^^^^^^^^^^^^^^^^^^^

>> Dateinamen zum Speichern vorgeben kann) hilft hier Content Negotiation
>> oder URL-Rewrite, indem dem Browser ein .pdf vorgegaukelt wird, hinter
>> dem sich z. B. ein solches PHP-Script verbirgt.
>
> Wie kommst du denn jetzt darauf? Nicht ".pdf" in der URL ist relevant,
> sondern "Content-Type: application/pdf", und so einen Header kann ein
> PHP-Skript genauso erzeugen wie der Webserver.

Natürlich. Es ging in diesem Absatz darum, den Dateidownload in ein
benutzerdefiniertes Verzeichnis zu erzwingen. Das ist mit “Content-Type:
application/pdf” bzw. etwas anderem als “applicaton/octet-stream” nicht
immer der Fall.

> Andernfalls würden meine Beispiele ja auch gar nicht funktionieren […]

Deine Beispiele sind hier nicht anwendbar.


PointedEars
--
Es ist ein ohne Sinn und Verstand ausgeschnittener Teil von invalidem
HTML mit in MSIE funktionierendem JScript (allerdings fehlen hier zum
Funktionieren erforderliche Teile), erzeugt von Micros~1 AffrontPage.
(Dietmar Meier in <aq8afp$7cc0b$1...@ID-3767.news.dfncis.de>)

[Thomas 'PointedEars' Lahn]

Frank Müller wrote:

> Matthias Würfl schrieb:

>> Am 18.04.2013 10:14, schrieb Frank Müller:
>>> Der Browser sucht
>>> sich dann das passende schon raus.

>> Woher weiß der Browser, was das passende ist?

>
> Ich nehme mal an der geht nach der Datei-Endung.

Kommt auf den Browser (und dessen Patch-Status, das ist nämlich eine
Sicherheitslücke) an. Wenn man sichergehen will, sendet man das passende
“Content-Type”-Headerfeld. Am einfachsten, indem man den Server geeignet
konfiguriert bzw. die Serveranwendung geeignet programmiert.

Das kann auch “application/octet-stream” sein, wenn man den Download
erzwingen will. Man muss sich aber über die Folgen für den Benutzer im
Klaren sein.

>>> Ich finde es jedenfalls immer lästig, wenn ich nur mal sehen will was da
>>> steht und muß deshalb die ganze PDF erst downloaden um sie mir

>>> anzusehen.
>>
>> Wie sieht die Alternative aus? Wie kannst Du sie sehen, ohne sie
>> vorher heruntergeladen zu haben?
>

> Größeren PDF-Dateien zeigt mir das Adobe-Acrobat-Plugin
> die ersten Seiten während die Datei noch lädt.

ACK. Auch andere PDF-Plugins können das. Und wenn man Google Docs benutzt,
wird das PDF-Dokument zum Betrachten nicht einmal als solches
heruntergeladen.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

[Gustaf Mossakowski]

Christoph Schneegans schrieb:

> Fr�her habe ich PDF-Dokumente gerne mit einem HTTP-Header

>
> Content-Disposition: attachment; filename=foo.pdf
>
> ausgeliefert. Das hatte gleich mehrere Vorteile:
>

> - Die Anzeige erfolgte nicht "inline" im Browser, sondern in einem
> eigenen Proze�, was typischerweise die Stabilit�t verbesserte.
> - Auch ein unbedarfter Anwender konnte das PDF-Dokument bequem
> abspeichern.

Ich schicke, wenn der Link �Download bla bla� lautet, ein PDF mit
Content-Disposition: attachment raus, sonst mit Content-Disposition:
inline. Jeder nutzt den Browser so mit seinen Einstellungen, wie er oder
sie will, ich denke, das sollte man beachten. Wenn viele Probleme haben,
den Browser korrekt einzustellen, mu� ich als Webautor nicht versuchen,
das f�r meine Sites zu regeln. Das ist dann eher eine Aufgabe der
Browserhersteller. YMMV.

filename=... und, falls notwendig, filename*=... sende ich immer mit, da
ich es selber sehr angenehm finde, wenn der Dateiname des PDF sinnvoll
ist. Das kann, mu� aber nicht der URL-Bestandteil sein. Beispiel:

http://example.org/reports/2010/q1.pdf

k�nnte sehr gut als

Example Corporation Report Q1-2010.pdf

auf dem Rechner landen. Deutlich besser als "q1.pdf" ohne
Content-Disposition.

Viele Gr��e, Gustaf

[Christoph Schneegans]

Gustaf Mossakowski schrieb:

> Ich schicke, wenn der Link �Download bla bla� lautet, ein PDF mit

> Content-Disposition: attachment raus, sonst mit Content-Disposition:
> inline. Jeder nutzt den Browser so mit seinen Einstellungen, wie er oder
> sie will, ich denke, das sollte man beachten.

Bei 'Content-Disposition: inline' wird sich ein Browser doch so
verhalten wie ganz ohne Content-Disposition-Header, oder?

[Matthias Würfl]

Am 18.04.2013 14:58, schrieb Frank Müller:
> Matthias Würfl schrieb:

>> Am 18.04.2013 10:14, schrieb Frank Müller:
>>> Der Browser sucht
>>> sich dann das passende schon raus.
>>

>> Woher weiß der Browser, was das passende ist?

>
> Ich nehme mal an der geht nach der Datei-Endung.

Der Browser hat 3 Optionen:

- Content-Type (http-header)
- Dateiendung
- Analyse der empfangenen Daten

Der Browser sollte sich nach dem Content-Type richten und die meisten
tun das auch. Es gibt allerdings beim IE zumindest einige Versionen,
welche unter bestimmten Umständen etwas anderes tun. Zumindest dass
Dateien mit HTML drinne als HTML gerendert wurden obwohl sie mit dem
Content-Type "text/plain" gesendet wurden habe ich schon live gesehen.

(suchsuchsuchsuchsuch-ah-da:)

http://msdn.microsoft.com/en-us/library/ms775147.aspx

Grüße, Matthias

[Claus Reibenstein]

Christoph Schneegans schrieb:

> Bei 'Content-Disposition: inline' wird sich ein Browser doch so
> verhalten wie ganz ohne Content-Disposition-Header, oder?

Habe mal ein wenig geforscht und in RFC 2183 dieses gefunden:
"Content-Disposition is an optional header field. In its absence, the
MUA may use whatever presentation method it deems suitable."

Die Antwort auf Deine Frage dï¿œrfte demnach "nein" lauten.

Gruￜ
Claus

[Thomas 'PointedEars' Lahn]

Claus Reibenstein wrote:

> Christoph Schneegans schrieb:
>> Bei 'Content-Disposition: inline' wird sich ein Browser doch so
>> verhalten wie ganz ohne Content-Disposition-Header, oder?
>
> Habe mal ein wenig geforscht und in RFC 2183 dieses gefunden:
> "Content-Disposition is an optional header field. In its absence, the
> MUA may use whatever presentation method it deems suitable."
>

> Die Antwort auf Deine Frage dürfte demnach "nein" lauten.

“MUA” steht für ”Mail User Agent”.

HTH

PointedEars
--
Du fragst Leute, die normalerweise gern Information weitergeben, wie Du
Information verheimlichen kannst? Ist das nicht ein bisschen ... nunja ...
seltsam? (Ulrich 'Droeppez' Kritzner zu einem Quelltextsperrer in
http://selfhtml.de/forum/zeigebeitrag.php3?fid=2&id=39654&thread=39241)