poeml@cmdline.net wrote:
On Tue, Jan 18, 2005 at 10:33:52AM +0100, Torsten Foertsch wrote:
On Monday 17 January 2005 21:10, christian zimmermann wrote:
Da gibt es doch bestimmt Logs.
10.4.0.1 - - [18/Jan/2005:11:04:39 +0100] "GET /scripts/css/basic.css HTTP/1.1" 200 2551 10.4.0.1 - - [18/Jan/2005:11:04:39 +0100] "GET /scripts/css/colors.css HTTP/1.1" 200 1713 10.4.0.1 - - [18/Jan/2005:11:04:39 +0100] "GET /scripts/css/fontsize_1.css HTTP/1.1" 200 297 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /scripts/css/gesundheit.css HTTP/1.1" 200 145 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/navigation/menupfeil_rechts.gif HTTP/1.1" 200 61 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/navigation/menustrich_rechts.gif HTTP/1.1" 200 55 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/bullets/selbstmed.gif HTTP/1.1" 200 753 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/bullets/popup.gif HTTP/1.1" 200 680 10.4.0.1 - - [18/Jan/2005:11:04:47 +0100] "GET /scripts/css/basic.css HTTP/1.1" 304 20 10.4.0.1 - - [18/Jan/2005:11:04:47 +0100] "GET /scripts/css/colors.css HTTP/1.1" 304 20 10.4.0.1 - - [18/Jan/2005:11:04:47 +0100] "GET /scripts/css/fontsize_1.css HTTP/1.1" 304 20 10.4.0.1 - - [18/Jan/2005:11:05:03 +0100] "GET /images/assets/bullets/selbstmed.gif HTTP/1.1" 304 - 10.4.0.1 - - [18/Jan/2005:11:05:04 +0100] "GET /images/assets/navigation/menupfeil_rechts.gif HTTP/1.1" 304 - 10.4.0.1 - - [18/Jan/2005:11:05:04 +0100] "GET /images/assets/bullets/popup.gif HTTP/1.1" 304 - 10.4.0.1 - - [18/Jan/2005:11:05:04 +0100] "GET /images/assets/navigation/menustrich_rechts.gif HTTP/1.1" 304 - hier der erste aufruf und danach der reload.
und die StyleSheets fehlen in der Seite. Ers nach dem leeren des caches
Was genau heisst "fehlen in der Seite"?
Die Seite wird ohne css angezeigt.
Das ist eigentlich ein Problem Deines Browsers oder Proxies. Er
überträgt nämlich in der Anfrage einen if-modified-since Header oder sowas ähnliches, obwohl er das Dokument nicht vorrätig hat (bzw. nicht bereit ist anzuzeigen).
Merkwürdig, ich habe es mit 4 Verschiedenen Browsern getestet und bei allen das selbe. Und wie gesagt dies betrifft nur ssl verschlüsselte verbindungen.
Richtig.
Peter
Any hints? Gruss Christian
On Tuesday 18 January 2005 11:42, christian zimmermann wrote:
Merkwürdig, ich habe es mit 4 Verschiedenen Browsern getestet und bei allen das selbe. Und wie gesagt dies betrifft nur ssl verschlüsselte verbindungen.
Dann nimm mal einen Firefox, installiere LiveHTTPHeaders (http://livehttpheaders.mozdev.org/) und schau zu, was passiert. Die übertragenen Header sind interessant. Torsten
Torsten Foertsch wrote:
On Tuesday 18 January 2005 11:42, christian zimmermann wrote:
Merkwürdig, ich habe es mit 4 Verschiedenen Browsern getestet und bei allen das selbe. Und wie gesagt dies betrifft nur ssl verschlüsselte verbindungen.
Dann nimm mal einen Firefox, installiere LiveHTTPHeaders (http://livehttpheaders.mozdev.org/) und schau zu, was passiert. Die übertragenen Header sind interessant.
Hab ich gemacht sehr nettes tool. ich habs nun mit mod_header gelöst, und es scheint zu funktioniern. Danke an alle für´s mittdenken.
Torsten
Gruss Christian
On Tue, Jan 18, 2005 at 02:45:56PM +0100, christian zimmermann wrote:
(http://livehttpheaders.mozdev.org/) und schau zu, was passiert. Die übertragenen Header sind interessant.
Hab ich gemacht sehr nettes tool. ich habs nun mit mod_header gelöst, und es scheint zu funktioniern. Danke an alle für´s mittdenken.
Wie waer's, wenn Du beschreibst, was genau Du geloest hast und wie? Bisher ist mir nicht einmal klar, was das Problem gewesen sein soll. Dann haetten alle was davon. Peter
poeml@cmdline.net wrote:
Wie waer's, wenn Du beschreibst, was genau Du geloest hast und wie? Bisher ist mir nicht einmal klar, was das Problem gewesen sein soll.
Dann haetten alle was davon.
Peter
Christian
On Tuesday 04 January 2000 03:37, christian zimmermann wrote:
Order allow,deny Allow from all Header set Cache-Control: "no-cache max-age=0, no-store" </Directory>
hoffentlich hast Du das nur in dem VirtualHost auf Port 443 so gemacht. Außerdem löst das Dein Problem nicht wirklich. Du setzt hier einen Output Header und verbietest das Caching. Wenn nun aber doch ein Browser so tut als würde er cachen und liefert einen if-not-modified-since oder if-match oder so Header, dann würde der Apache weiterhin korrekt mit 304 (NOT_MODIFIED) antworten. Richtiger wäre wahrscheinlich, mit RequestHeader die paar if-* Header aus RFC 2616 (bei mir im RPM rfc-2004.10.5-1) zu löschen. Hast Du das mal probiert? Torsten
christian zimmermann wrote:
Torsten Foertsch wrote:
Richtiger wäre wahrscheinlich, mit RequestHeader die paar if-* Header aus RFC 2616 (bei mir im RPM rfc-2004.10.5-1) zu löschen. Hast Du das mal probiert?
Torsten
Ich werds gleich mal testen.
Also ich habe mal versucht mittels
On Monday 24 January 2005 12:21, christian zimmermann wrote: > christian zimmermann wrote: > > Torsten Foertsch wrote: > >> Richtiger wäre wahrscheinlich, mit RequestHeader die paar if-* > >> Header aus RFC 2616 (bei mir im RPM rfc-2004.10.5-1) zu löschen. Hast > >> Du das mal probiert? > >> > >> Torsten > > > > Ich werds gleich mal testen. > > Also ich habe mal versucht mittels > >> Order allow,deny > Allow from all > RequestHeader unset If-Modified-Since > > > > Diesen Header zu entfernen, aber scheinbar greift dieser erst gar nicht. > Es erscheint weiterhin dieser Header und in den Websrv. logs ein 304. > > Der syntax ist aber korrekt? oder irre ich mich Also, ich habe jetzt mal ein paar Experimente gemacht: 1. einfach ein File holen: > curl -v http://localhost/selfhtml/index.htm -o /dev/null -s * About to connect() to localhost port 80 * Connected to localhost (127.0.0.1) port 80 > GET /selfhtml/index.htm HTTP/1.1 User-Agent: curl/7.12.0 (i686-suse-linux) libcurl/7.12.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1 Host: localhost Pragma: no-cache Accept: */* < HTTP/1.1 200 OK < Date: Mon, 24 Jan 2005 13:48:55 GMT < Server: Apache/2.0.52 (Linux/SUSE) < Last-Modified: Sat, 27 Oct 2001 08:00:00 GMT < ETag: "31a27-2662-744d6000" < Accept-Ranges: bytes < Content-Length: 9826 < Content-Type: text/html; charset=ISO-8859-1 * Connection #0 to host localhost left intact * Closing connection #0 Im Logfile erschien: 127.0.0.1 - - [24/Jan/2005:14:48:55 +0100] "GET /selfhtml/index.htm HTTP/1.1" 200 9826 "-" "curl/7.12.0 (i686-suse-linux) libcurl/7.12.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1" 2. das Ganze mit If-Modified-Since Header: > curl -v http://localhost/selfhtml/index.htm -o /dev/null -s -H 'If-Modified-Since: Sat, 27 Oct 2001 08:00:00 GMT' * About to connect() to localhost port 80 * Connected to localhost (127.0.0.1) port 80 > GET /selfhtml/index.htm HTTP/1.1 User-Agent: curl/7.12.0 (i686-suse-linux) libcurl/7.12.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1 Host: localhost Pragma: no-cache Accept: */* If-Modified-Since: Sat, 27 Oct 2001 08:00:00 GMT < HTTP/1.1 304 Not Modified < Date: Mon, 24 Jan 2005 13:51:31 GMT < Server: Apache/2.0.52 (Linux/SUSE) < ETag: "31a27-2662-744d6000" * Connection #0 to host localhost left intact * Closing connection #0 Wie erwartet status=304. Im Logfile erscheint: 127.0.0.1 - - [24/Jan/2005:14:51:31 +0100] "GET /selfhtml/index.htm HTTP/1.1" 304 - "-" "curl/7.12.0 (i686-suse-linux) libcurl/7.12.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1" 3. Jetzt ergänze ich die httpd.conf um: RequestHeader unset If-Modified-Since und mach das nochmal: > curl -v http://localhost/selfhtml/index.htm -o /dev/null -s -H 'If-Modified-Since: Sat, 27 Oct 2001 08:00:00 GMT' * About to connect() to localhost port 80 * Connected to localhost (127.0.0.1) port 80 > GET /selfhtml/index.htm HTTP/1.1 User-Agent: curl/7.12.0 (i686-suse-linux) libcurl/7.12.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1 Host: localhost Pragma: no-cache Accept: */* If-Modified-Since: Sat, 27 Oct 2001 08:00:00 GMT < HTTP/1.1 200 OK < Date: Mon, 24 Jan 2005 14:17:38 GMT < Server: Apache/2.0.52 (Linux/SUSE) < Last-Modified: Sat, 27 Oct 2001 08:00:00 GMT < ETag: "31a27-2662-744d6000" < Accept-Ranges: bytes < Content-Length: 9826 < Content-Type: text/html; charset=ISO-8859-1 * Connection #0 to host localhost left intact * Closing connection #0 Jetzt kommt Status 200. Im Logfile erscheint: 127.0.0.1 - - [24/Jan/2005:15:17:38 +0100] "GET /selfhtml/index.htm HTTP/1.1" 200 9826 "-" "curl/7.12.0 (i686-suse-linux) libcurl/7.12.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1" D.h. RequestHeader unset Anweisung funktioniert. Folgendes passiert aber. Wenn ich die RequestHeader Anweisung in einen Location Block packe funktioniert es. Dann habe ich es noch mit einem Directory Block probiert in 2 Varianten. Bei mir ist /srv/www/htdocs/selfhtml ein symbolic Link auf /usr/share/doc/selfhtml. Schreibe ich also /srv/www/htdocs/selfhtml in den Directory Block funktioniert es weiterhin, mit /usr/share/doc/selfhtml aber nicht. Ist Dein /home/web/scripts/ vielleicht über einen Symlink in das DocumentRoot geraten? Torsten
Hi Torsten, es ist in der tat so /home/web/ und alles darunter ist ein symbolischer link auf ein HA FS. Hast du einen Lösungsansatz? Gruss Christian Torsten Foertsch wrote:
D.h. RequestHeader unset Anweisung funktioniert.
Folgendes passiert aber. Wenn ich die RequestHeader Anweisung in einen Location Block packe funktioniert es. Dann habe ich es noch mit einem Directory Block probiert in 2 Varianten. Bei mir ist /srv/www/htdocs/selfhtml ein symbolic Link auf /usr/share/doc/selfhtml. Schreibe ich also /srv/www/htdocs/selfhtml in den Directory Block funktioniert es weiterhin, mit /usr/share/doc/selfhtml aber nicht.
Ist Dein /home/web/scripts/ vielleicht über einen Symlink in das DocumentRoot geraten?
Torsten
On Monday 24 January 2005 18:34, christian zimmermann wrote:
Hi Torsten,
es ist in der tat so /home/web/ und alles darunter ist ein symbolischer link auf ein HA FS. Hast du einen Lösungsansatz?
Der ist doch eigentlich ersichtlich. Alias oder <Location> oder <Directory> so wie der Apache
das Verzeichnis sieht. Um an meinem Beispiel zu bleiben:
ls -l /srv/www/htdocs/selfhtml
lrwxrwxrwx 1 root root 23 2004-12-30 16:28 /srv/www/htdocs/selfhtml -> /usr/share/doc/selfhtml
Torsten Foertsch wrote:
D.h. RequestHeader unset Anweisung funktioniert.
Folgendes passiert aber. Wenn ich die RequestHeader Anweisung in einen Location Block packe funktioniert es. Dann habe ich es noch mit einem Directory Block probiert in 2 Varianten. Bei mir ist /srv/www/htdocs/selfhtml ein symbolic Link auf /usr/share/doc/selfhtml. Schreibe ich also /srv/www/htdocs/selfhtml in den Directory Block funktioniert es weiterhin, mit /usr/share/doc/selfhtml aber nicht.
Ist Dein /home/web/scripts/ vielleicht über einen Symlink in das DocumentRoot geraten?
Torsten
On Tue, Jan 04, 2000 at 03:37:28AM +0100, christian zimmermann wrote:
Wie waer's, wenn Du beschreibst, was genau Du geloest hast und wie? Bisher ist mir nicht einmal klar, was das Problem gewesen sein soll.
Order allow,deny Allow from all Header set Cache-Control: "no-cache max-age=0, no-store" </Directory> seit dem werden die css files auch über ssl bei einem reload der page geladen. was vorher nicht der fall war. getestet auf 3 webservern mit 4 browsern.
Gut, soweit der Workaround. Das klaert leider nicht das zugrundeliegende Problem auf, das mit dem Workaround behoben wird. Ausserdem werden die css-Files jetzt nicht mehr gecached. Die Kernfrage bleibt: Warum verhielten sich die Browser so, wie sie sich verhielten. Peter
On Monday 24 January 2005 18:11, poeml@cmdline.net wrote:
On Tue, Jan 04, 2000 at 03:37:28AM +0100, christian zimmermann wrote:
Wie waer's, wenn Du beschreibst, was genau Du geloest hast und wie? Bisher ist mir nicht einmal klar, was das Problem gewesen sein soll.
Order allow,deny Allow from all Header set Cache-Control: "no-cache max-age=0, no-store" </Directory> seit dem werden die css files auch über ssl bei einem reload der page geladen. was vorher nicht der fall war. getestet auf 3 webservern mit 4 browsern.
Gut, soweit der Workaround. Das klaert leider nicht das zugrundeliegende Problem auf, das mit dem Workaround behoben wird. Ausserdem werden die css-Files jetzt nicht mehr gecached.
Die Kernfrage bleibt: Warum verhielten sich die Browser so, wie sie sich verhielten.
Dem kann ich nur zustimmen. Damit solltest Du Dich beschäftigen. Torsten
On Tue, Jan 18, 2005 at 11:42:05AM +0100, christian zimmermann wrote:
10.4.0.1 - - [18/Jan/2005:11:04:39 +0100] "GET /scripts/css/basic.css HTTP/1.1" 200 2551 10.4.0.1 - - [18/Jan/2005:11:04:39 +0100] "GET /scripts/css/colors.css HTTP/1.1" 200 1713 10.4.0.1 - - [18/Jan/2005:11:04:39 +0100] "GET /scripts/css/fontsize_1.css HTTP/1.1" 200 297 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /scripts/css/gesundheit.css HTTP/1.1" 200 145 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/navigation/menupfeil_rechts.gif HTTP/1.1" 200 61 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/navigation/menustrich_rechts.gif HTTP/1.1" 200 55 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/bullets/selbstmed.gif HTTP/1.1" 200 753 10.4.0.1 - - [18/Jan/2005:11:04:40 +0100] "GET /images/assets/bullets/popup.gif HTTP/1.1" 200 680 10.4.0.1 - - [18/Jan/2005:11:04:47 +0100] "GET /scripts/css/basic.css HTTP/1.1" 304 20 10.4.0.1 - - [18/Jan/2005:11:04:47 +0100] "GET /scripts/css/colors.css HTTP/1.1" 304 20 10.4.0.1 - - [18/Jan/2005:11:04:47 +0100] "GET /scripts/css/fontsize_1.css HTTP/1.1" 304 20 10.4.0.1 - - [18/Jan/2005:11:05:03 +0100] "GET /images/assets/bullets/selbstmed.gif HTTP/1.1" 304 - 10.4.0.1 - - [18/Jan/2005:11:05:04 +0100] "GET /images/assets/navigation/menupfeil_rechts.gif HTTP/1.1" 304 - 10.4.0.1 - - [18/Jan/2005:11:05:04 +0100] "GET /images/assets/bullets/popup.gif HTTP/1.1" 304 - 10.4.0.1 - - [18/Jan/2005:11:05:04 +0100] "GET /images/assets/navigation/menustrich_rechts.gif HTTP/1.1" 304 -
Das sieht normal aus.
hier der erste aufruf und danach der reload.
Beim zweiten Aufruf macht der Browser bzw. der Cache einen konditionalen GET-Request, zB If-modified-since, und bekommt zur Antwort dass die Objekte noch frisch sind. Wobei, Cache faellt bei Dir ja aus, falls alle Requests ueber SSL gehen. Ist das auch wirklich so?
und die StyleSheets fehlen in der Seite. Ers nach dem leeren des caches
Was genau heisst "fehlen in der Seite"?
Die Seite wird ohne css angezeigt.
Das sollte nicht passieren. Ich wuerde das mal auf der Kommandozeile testen, um genau sehen zu koennen, was an der Antwort des Servers falsch sein soll. zB openssl s_client -connect hostname:port GET /scripts/css/basic.css HTTP/1.0<enter> <enter> Und auf die Header achten. Oder mit ssldump den Verkehr mitschneiden.
Das ist eigentlich ein Problem Deines Browsers oder Proxies. Er überträgt nämlich in der Anfrage einen if-modified-since Header oder sowas ähnliches, obwohl er das Dokument nicht vorrätig hat (bzw. nicht bereit ist anzuzeigen).
Was mir noch einfallen wuerde, schau mal ob die Zeit auf den beiden Rechnern stark voneinander abweicht.
Merkwürdig, ich habe es mit 4 Verschiedenen Browsern getestet und bei allen das selbe. Und wie gesagt dies betrifft nur ssl verschlüsselte verbindungen.
Das ist merkwuerdig. Peter
participants (4)
-
christian zimmermann -
christian zimmermann -
poeml＠cmdline.net -
Torsten Foertsch