AW: Altes Thema, neu aufgewärmt: Der AlbumMaker
Spinnt die Dropbox?
M.E.:
Ja!
Wie Recht Manfred (Stups) doch hatte mit seiner Anmerkung aus
dem Beitrag 534:
... Mir scheint, der AlbumMaker ist ein Werkzeug zum Testen von "eigenartig" arbeitenden Programmen. AlbumMaker erkennt und deckt gnadenlos deren Unartigkeiten auf...
Zur Erinnerung:
Manfred hatte mit dem AlbumMaker ein kleines Album namens
"Gaustablikk mit Gaustatoppen im März 2013" generiert und auf die Dropbox hochgeladen. Er stellte verwundert fest, dass bei Aufruf und Großanzeige der darin enthaltenen Bilder, die in der Bildunterschrift enthaltenen Umlaute in einem falschen Charakter-Satz dargestellt wurden (inzwischen korrigiert).
Die daraufhin angestellten Vermutungen, dass sein Browser beim Albumaufruf den Text aus den HTML-Seiten in einem falschen "Charset" darstellen oder gar die HTML-Seiten falsch vom AlbumMaker generiert würden, erwiesen sich als falsch. Die Gegenprobe, das Album auf einen "regulären" Server hochgeladen, zeigte alle Textinhalte in korrekter Darstellung. Verwunderlich war dabei auch, dass die Albumüberschrift (die ebenfalls einen Umlaut beinhaltet) fehlerfrei wiedergegeben wurde.
Ich habe mich dann mit großer Akribie dieser Problematik gewidmet und eine Menge Zeit investiert. Schließlich stellte sich folgendes seltsame Verhalten der Dropbox heraus:
Beim Aufruf einer auf einem Server abgelegten HTML-Seite wird vor der eigentlichen Übertragung der Seite an den aufrufenden Browser ein sogenannter
HTTP-Header übertragen, damit der Browser diese Seite auch korrekt als HTML-Seite darstellen kann. Um nun die weitere Problematik besser darstellen zu können, habe ich hier mal über
diesen Link ein kleines Testalbum erstellt.
Für die Ermittlung des von der Dropbox gesendeten HTTP-Headers kann man sich einer
Freeware-Routine bedienen , die beim Aufruf des Album-Links auf der Dropbox folgenden HTTP-Header liefert:
Code:
Resultate des GSiteCrawler Server-Tests
Getestet am/um 3/29/2013 6:03:11 PM / von 79.237.73.225:
URL=http://dl.dropbox.com/u/155401846/Testalbum/index.html
Result code: 200 (OK / OK)
Server: nginx/1.2.6
Date: Fri, 29 Mar 2013 18:03:12 GMT
[B][U]Content-Type: text/html; charset=ISO-8859-1[/U][/B]
Content-Length: 7591
x-robots-tag: noindex,nofollow
Accept-Ranges: bytes
x-server-response-time: 1006
ETag: 496n
x-dropbox-request-id: 5a01c723609e6ffa
Pragma: public
Cache-Control: max-age=0
Dies ist soweit völlig korrekt und die unterstrichen markierte Zeile gibt dem Browser mit ISO-8859-1 völlig einwandfrei den gewünschten Charset vor.
Überprüft man aber jetzt den von der Dropbox gesendeten HTTP-Header für die HTML-Seite eines Großbildes (
z.B.), so erhält man folgende Header-Angabe:
Code:
Resultate des GSiteCrawler Server-Tests
Getestet am/um 3/29/2013 6:11:38 PM / von 79.237.73.225:
URL=http://dl.dropbox.com/u/155401846/Testalbum/dom11_012.html
Result code: 200 (OK / OK)
Server: nginx/1.2.6
Date: Fri, 29 Mar 2013 18:11:38 GMT
[B][U]Content-Type: text/html; charset=ISO-8859-7[/U][/B]
Content-Length: 9994
x-robots-tag: noindex,nofollow
Accept-Ranges: bytes
x-server-response-time: 572
ETag: 497n
x-dropbox-request-id: 31b615fcdf646e4f
Pragma: public
Cache-Control: max-age=0
Nun lautet plötzlich (siehe unterstrichene Zeile) die Charset-Angabe ISO-8859-7, die den Browser veranlasst, die Umlaute "verstümmelt" wiederzugeben. Welcher Charset im Header von der Dropbox geliefert wird, ist nach meinen Beobachtungen stark zufallsbedingt. Häüfig meldet die Dropbox auch: Charset=windows-1255, was die Umlaute zwar anders aber auch verstümmelt darstellt.
Dabei dürfte dies in keiner Weise geschehen! Alle vom AlbumMaker generierten HTML-Seiten weisen die gleichen nach Vorgabe des W3C-HTML-Konsortium empfohlenen Kopfzeilen aus:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1" >
Diese Kopfzeilen beinhalten völlig korrekt und vorschriftsmäßig die meta-Angabe zum verwendeten charset=ISO-8859-1, was aber die Dropbox nicht im geringsten stört und von ihr völlig außer Acht gelassen wird.
Als Vermeidungsstrategie habe ich bisher die folgenden beiden Lösungen herausgefunden:
- Alle Umlaute und "ß" im Text der HTML-Seiten werden durch die für HTML vorgegebenen Umschreibungen ersetzt (z.B. "ä" durch "ä"). Dies ist natürlich trivial, bedeutet aber zusätzlichen Aufwand beim Generieren der HTML-Seiten und macht die Seite in Abhängigkeit von der Textmenge unnötig umfangreicher. Übrigens wird diese Methode auch bei der Albumerstellung mit der HomeGallery verwendet.
- Eine empirisch gefundene Verlängerung der HTML-Seite (z.B.: durch HTML-Kommentare) lässt ab einer bestimmten Dateigröße plötzlich die Dropbox dazu bewegen, doch wieder einen korrekten HTTP-Haeder zu erstellen und zu senden. Auch diese Lösung bedeutet aber ein zusätzliches Aufblähen der HTML-Seiten und das nur, um die Dropbox auf "Vordermann" zu bringen.
Als Demo habe ich das
Albumbild 2 zusätzlich mit HTML-Ersetzungen generiert und separat hochgeladen; damit wird dann im HTTP_Header die betreffende Zeile korrekt geliefert:
Code:
...
[B][U]Content-Type: text/html; charset=ISO-8859-1[/U][/B]
...
Das
Albumbild 3 habe ich als weiteres Beispiel mit zusätzlichen HTML-Kommentar verlängert, was ebenfalls im HTTP-Header wie gewünscht liefert:
Code:
...
[B][U]Content-Type: text/html; charset=ISO-8859-1[/U][/B]
...
Warum die zweite Lösung ebenfalls funktioniert, ist mir völlig unerklärlich und nicht nachvollziehbar. Doch eins ist damit sicher:
Die Dropbox spinnt! (oder doch der AlbumMaker bzw. sein Ersteller)
Es würde mich freuen, wenn jemand aus dem Forum eine plausible Erklärung für dieses myteriöse Verhalten hat und sie hier diskutieren würde. Soviel ich weiß, haben wir ja einige HTML-Spezialisten hier im Forum, die uns bestimmt weiter helfen können.
Schöne Ostergrüße
Heinrich
. Es wird jetzt zwar kein Leereintrag mehr in der 
.
;D