nicht angemeldet
gzip Probleme bei Mozilla 1.7 und Opera 7.5: Bug oder Feature?
Hallo,
ich habe als statische gzip-Lösung folgende Einträge i.d. htaccess:
Options +Multiviews
AddEncoding gzip .gz
und dann die Dateien:
xyz.html.html
xyz.html.gz
Jetzt verhalten sich Mozilla 1.7 und Opera 7.5 anders als frühere Browser,
nach Aufruf von "xyz.html" werden die Ziele innerhalb der Datei, also #ziel,
nicht als xyz.html#ziel sondern als xyz.html.gz#ziel gesucht, abgesehen
von der unschönen Adresse wird xyz.html.gz auch noch erneut geladen.
Was ist zu tun, oder sind es nur Bugs der Betaversionen?
Gruß
CurtB
-
Moin,
Jetzt verhalten sich Mozilla 1.7 und Opera 7.5 anders als frühere Browser,
nach Aufruf von "xyz.html" werden die Ziele innerhalb der Datei, also #ziel,
nicht als xyz.html#ziel sondern als xyz.html.gz#ziel gesucht, abgesehen
von der unschönen Adresse wird xyz.html.gz auch noch erneut geladen.Was ist zu tun, oder sind es nur Bugs der Betaversionen?
Hmm, ich wollte deiner Beschreibung erst nicht glauben, kann das hier aber reproduzieren. Nähere Untersuchung zeigt, dass der Apache den URL mit .gz hintendran in einem Content-Location-Header sendet, wie das RFC 2616 auch empfiehlt. An der selben Stelle (Abschnitt 14.14) steht auch, dass dieser Header, wenn vorhanden, den Base-URI für die HTML-Seite festlegt. Die beiden Browser verhalten sich also korrekt, und strenggenommen ist das beobachtete Verhalten der anderen Browser ein Bug.
(Mark hat unter http://diveintomark.org/archives/2004/01/02/relative-uris einen Artikel der das Thema streift.)
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Hallo,
von der unschönen Adresse wird xyz.html.gz auch noch erneut geladen.
Was ist zu tun, oder sind es nur Bugs der Betaversionen?
Hmm, ich wollte deiner Beschreibung erst nicht glauben, kann das hier aber reproduzieren. Nähere Untersuchung zeigt, dass der Apache den URL mit .gz hintendran in einem Content-Location-Header sendet, wie das RFC 2616 auch empfiehlt. An der selben Stelle (Abschnitt 14.14) steht auch, dass dieser Header, wenn vorhanden, den Base-URI für die HTML-Seite festlegt. Die beiden Browser verhalten sich also korrekt, und strenggenommen ist das beobachtete Verhalten der anderen Browser ein Bug.
besten Dank für die Info.
Es besteht also eine gewisse Wahrscheinlichkeit dass Opera und Mozilla sich in Zukunft weiterhin so verhalten, und einfache
Tricksereien am Server per htaccess gibts vmtl. nicht, da bleibt wohl nur ein Versuch mit <base href="http://www...../xyz.html">.
Ein relativer Pfad läßt sich so aber leider nicht anwenden.Gruß
CurtB -
Hallo,
Jetzt verhalten sich Mozilla 1.7 und Opera 7.5 anders als frühere Browser,
Konqueror/Safari macht es übrigens auch, soweit ich weiß.
nach Aufruf von "xyz.html" werden die Ziele innerhalb der Datei, also #ziel, nicht als xyz.html#ziel sondern als xyz.html.gz#ziel gesucht, abgesehen von der unschönen Adresse wird xyz.html.gz auch noch erneut geladen.
Was ist zu tun, oder sind es nur Bugs der Betaversionen?
Hmm, ich wollte deiner Beschreibung erst nicht glauben, kann das hier aber reproduzieren. Nähere Untersuchung zeigt, dass der Apache den URL mit .gz hintendran in einem Content-Location-Header sendet, wie das RFC 2616 auch empfiehlt. An der selben Stelle (Abschnitt 14.14) steht auch, dass dieser Header, wenn vorhanden, den Base-URI für die HTML-Seite festlegt. Die beiden Browser verhalten sich also korrekt, und strenggenommen ist das beobachtete Verhalten der anderen Browser ein Bug.
Das ist gleich dreifach »dumm gelaufen« und unterminiert m.M.n. die meisten sinnvollen Anwendungszwecke von MultiViews.
1. MultiViews wird eingesetzt, um unter einer URL verschiedene Inhalte je nach Anfrage zu anzubieten (Kodierung, Sprache usw.). Das ergibt nur Sinn, wenn diese URL die einzige nach außen sichtbare Adresse ist, die als solche in der Adressleiste auftaucht, verlinkt wird, in Suchmaschinen auftaucht etc. So kommen aber alle dahinterliegenden URLs zum Vorschein. Jemand linkt auf die Version, die er gerade aufgrund seiner jeweiligen Einstellungen ausgeliefert bekommen hat. Damit ist die gesamte Negotiation für die Katz.
2. Wenn xyz.html aufgerufen wird und xyz.html.(gz|html) zurückgegeben wird, dann der anker #ziel angesprungen wird, wird die Ressource noch einmal unter der Content-Location-URL komplett vom Server bezogen. Damit wird die Negotiation nach GZip-Komprimierung hinfällig, da das Dokument zweimal übertragen wird, wenn dokumentinterne Anker eingesetzt werden.
Schön zu sehen an der Apache-Doku:
http://httpd.apache.org/docs-2.0/mod/core.html
Ewig langes Dokument, extensiver Gebrauch von Ankern. Wenn in der dokumeninternen Navigation ein Eintrag gewählt wird, wird folgende URL benutzt (bei Accept-Language: de):
http://httpd.apache.org/docs-2.0/mod/core.html.de#acceptpathinfo
Es werden noch einmal ohne jegliche Notwendigkeit 182 KB übertragen (und die ersten 182 KB waren vollkommen umsonst)! Da frage ich mich, warum ich so dumm bin und einen RFC-konformen Browser verwende, das bringt mich immer wieder auf die Palme.3. MultiViews wird oft eingesetzt, um Dateien mit anderer Dateiendung (php, pl, cgi, py usw.) unter einer Adresse ohne besonderer Dateiendung (bla.html) zugänglich zu machen. So kann das Backend jederzeit geändert werden (bla.html kann bla.html entsprechend, aber auch bla.html.php, bla.html.pl usw.). Wenn die Browser aber die Content-Location-URL benutzen, fällt diese Möglichkeit weg, da die URLs sonst sterben würden.
Kurzum: Was sich die RFC-Schreiber da ausgedacht haben, ist hinsichtlich der obigen Situation ein großes Übel. Der Ausweg ist höchstens eine mod_rewrite-Regel, sodass Content-Location nie gesendet wird (mir ist keine Möglichkeit bekannt, mod_negotation entsprechend zu konfigurieren).
Mathias
-