Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PDFs immer noch mit Content-Disposition-Header ausliefern?
32 views
Skip to first unread message
Christoph Schneegans
Apr 17, 2013, 6:09:50 PM4/17/13
to
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>
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
Apr 17, 2013, 8:50:15 PM4/17/13
to
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
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>)
> [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
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
Apr 18, 2013, 4:14:14 AM4/18/13
to
Christoph Schneegans schrieb:
> Hallo allerseits
>
> Früher™ habe ich PDF-Dokumente gerne mit einem HTTP-Header
> 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
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
> 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
> 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
> Content-Disposition: attachment; filename=foo.pdf
>
> ausgeliefert. Das hatte gleich mehrere Vorteile:
>
> 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,
> 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...
> 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?
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
Apr 18, 2013, 4:42:01 AM4/18/13
to
Am 18.04.2013 10:14, schrieb Frank Müller:
> Einfach verlinken, ohne irgendwas anzugeben.
Keine http-Header mitsenden? Hä?
> 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.
heruntergeladen zu haben?
Grüße, Matthias
Thomas 'PointedEars' Lahn
Apr 18, 2013, 5:22:06 AM4/18/13
to
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,
> Am 18.04.2013 10:14, schrieb Frank Müller:
>> Einfach verlinken, ohne irgendwas anzugeben.
>
> Keine http-Header mitsenden? Hä?
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?
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?
ist.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Christoph Schneegans
Apr 18, 2013, 5:42:39 AM4/18/13
to
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>
> 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.
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
Apr 18, 2013, 8:58:27 AM4/18/13
to
Matthias W�rfl schrieb:
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 ersten Seiten w�hrend die Datei noch l�dt.
Frank
> 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?
>> Der Browser sucht
>> sich dann das passende schon raus.
>
Ich nehme mal an der geht nach der Datei-Endung.
>> Ich finde es jedenfalls immer
>> 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
>
> Wie sieht die Alternative aus? Wie kannst Du sie sehen, ohne sie
> vorher heruntergeladen zu haben?
die ersten Seiten w�hrend die Datei noch l�dt.
Frank
Arno Welzel
Apr 18, 2013, 2:09:50 PM4/18/13
to
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
> 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.
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
Apr 18, 2013, 2:22:31 PM4/18/13
to
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
^^^^^^^^^^^^^^^^^^^^^^^^
> 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
>> 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.
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
Apr 18, 2013, 2:29:11 PM4/18/13
to
Frank Müller wrote:
> Matthias Würfl schrieb:
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
> 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>
> 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?
>>> Der Browser sucht
>>> sich dann das passende schon raus.
>
> Ich nehme mal an der geht nach der Datei-Endung.
Kommt auf den Browser (und dessen Patch-Status, das ist nämlich eine
> Ich nehme mal an der geht nach der Datei-Endung.
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
>>
>> Wie sieht die Alternative aus? Wie kannst Du sie sehen, ohne sie
>> vorher heruntergeladen zu haben?
>
> 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
Apr 18, 2013, 5:18:42 PM4/18/13
to
Christoph Schneegans schrieb:
> Fr�her habe ich PDF-Dokumente gerne mit einem HTTP-Header
> 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
> 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
> Content-Disposition: attachment; filename=foo.pdf
>
> ausgeliefert. Das hatte gleich mehrere Vorteile:
>
> 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
Apr 19, 2013, 4:30:44 AM4/19/13
to
Gustaf Mossakowski schrieb:
> Ich schicke, wenn der Link �Download bla bla� lautet, ein PDF mit
verhalten wie ganz ohne Content-Disposition-Header, oder?
> 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
> inline. Jeder nutzt den Browser so mit seinen Einstellungen, wie er oder
> sie will, ich denke, das sollte man beachten.
verhalten wie ganz ohne Content-Disposition-Header, oder?
Matthias Würfl
Apr 19, 2013, 4:44:32 AM4/19/13
to
Am 18.04.2013 14:58, schrieb Frank Müller:
> Matthias Würfl schrieb:
- 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
> 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?
>>> Der Browser sucht
>>> sich dann das passende schon raus.
>>
>
> Ich nehme mal an der geht nach der Datei-Endung.
Der Browser hat 3 Optionen:
> Ich nehme mal an der geht nach der Datei-Endung.
- 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
Apr 19, 2013, 7:29:09 AM4/19/13
to
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
> Bei 'Content-Disposition: inline' wird sich ein Browser doch so
> verhalten wie ganz ohne Content-Disposition-Header, oder?
"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
Apr 19, 2013, 7:36:40 AM4/19/13
to
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.
> 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."
>
“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)
0 new messages