[wiki] anzeigeprob startseite. stylesheet?

[Olodin]

Hallo,

beim Lesen im Wiki ist mir jetzt wiederholt aufgefallen, dass mir auf der Startseite das 'Menu' nicht angezeigt wird. Hab jetzt mal ein bisschen rumgeklickst, es aber nicht inbekommen.

Anbei zwei Screenshots: auf dem einen sieht man, wie die Startseite hier ausschaut. Der andere ist die Errorconsole vom Firefox beim aufrufen der Startseite.

Tests mit Firefox 3.0.6 auf Windows XP mit IE7 (Rechner auf der Arbeit). Surfe über einen Squid <2.7.STABLE6 for i386-portbld-freebsd7.0>. Plugins im Firefox hatte ich, bis auf einen ProxySwitcher, deaktiviert.

Vielleicht hilfts ja schon, dieses Stylesheet rauszuschmeissen. Das gibt es nicht:

<link rel="stylesheet" type="text/css" media="print" href="/lib/tpl/monobook/common/print.css" />

Habt ihr das auch schonmal gesehen? Hoffe, das ist so nicht gewollt!

[nakal]

Also das ist äußerst seltsam. So etwas habe ich noch nie gesehen.

Kannst Du auch normale Wikipedia ansehen? Oder ist da der gleiche Fehler?

Ich würde spontan auf Plugins und den Proxy tippen, die vielleicht nicht richtig funktionieren.

Das "print" Stylesheet sollte nur zum Drucken verwendet werden. Es sollte die Anzeige auf dem Monitor nicht stören.

[Olodin]

Zitat von nakal

Also das ist äußerst seltsam. So etwas habe ich noch nie gesehen.

Kannst Du auch normale Wikipedia ansehen? Oder ist da der gleiche Fehler?

Kein Problem mit Wikipedia (mediawiki). Hab zu Hause auch ne dokuwiki installation, was ja auch vom wiki hier genutzt wird: auch keine Probleme.

Das "print" Stylesheet sollte nur zum Drucken verwendet werden. Es sollte die Anzeige auf dem Monitor nicht stören.

Das ist klar. Aber das verlinkte Stylesheet gibt es gar nicht. Ruft den link oben mal auf:
http://wiki.bsdforen.de/lib/tpl/mono...mmon/print.css
Weils die Datei nicht gibt, landet der Link in der Wiki-Engine und es kommt eine "dieses Thema gibt es nicht"-Seite.

Das andere Print-Stylesheet gibt es:
http://wiki.bsdforen.de/lib/tpl/mono...ommonPrint.css

Mit elinks funktioniert die Startseite übrigens

Edit:
So, gerade mal zu Hause geschaut. Da gibts das print.css auch nicht. Also daran liegts bestimmt nicht. Hm, sehr komisch.

[nakal]

Also ich hör immer noch "Proxy" and da läuten bei mir paar Alarmglocken. Ist die HTML-Datei, die da ausgeliefert wird in beiden Fällen die gleiche? Hast Du die Quellcodes mal verglichen?

Was mir noch einfällt... eine falsche MTU-Einstellung kann die Webseite auch verändern, aber das bemerkt man eher durch lange Timeouts.

[Olodin]

Ich schau mir das mal heute abend zu Hause genauer an. Mit und ohne den Proxy. Vielleicht findet sich was, beim Vergleich der Seiten-Quelltexte.

[Olodin]

Hattest recht, der Proxy isses Ohne klappt es.

Hab die Quelltexte mit und ohne Proxy verglichen. Mit Proxy wird ab diesem Kommentar (Zeile 141 bei mir)

<!-- no cachefile used, caching forbidden -->

nichts mehr geladen. Es fehlen auch die schliessenden </body> und </html>. Hm.

Squid cache.log sagt im Moment des Aufrufs:

2009/02/25 20:21:19| Invalid chunk header '^M
'
2009/02/25 20:21:20| Invalid chunk header '^M
'
2009/02/25 20:21:20| Invalid chunk header '^M
'
2009/02/25 20:21:21| Invalid chunk header '^M
'
2009/02/25 20:21:22| Invalid chunk header '^M
'

Mal schaun, ob sich dazu was finden lässt.

[nakal]

Also, wie ich das sehe, liefert das Wiki Chunked Content. Was jetzt das Problem ist, ist wahrscheinlich das Missverständnis zwischen den drei Komponenten:

1. Internet Explorer (MS-Windows-Kram, mit MS-Windows-Encodings)
2. Squid (meistens Unix-Encodings, vielleicht kein Verständnis von MS-Windows-Encodings?)
3. Webseite (wahrscheinlich funktioniert beides wunderbar, sonst würden sich hier viele beschweren)

Der Browser scheint sich mit der Webseite auf ein Encoding der Zeilenenden (oder vielleicht geht es sogar um die Chunks direkt) geeinigt haben und Dein Proxy hat's wohl nicht mitgekriegt. Da der Proxy wohl die Header auswerten will, hat der Parser da versagt, wo das ^M (eigentlich ein Zeilenabschluss für MS-Windows-ASCII-Dateien) vorgefunden worden ist und abgebrochen.

Meine Vermutung ist, dass Squid nicht richtig konfiguriert ist (wie schon auch vorher, eigentlich).

[troll]

Zitat von nakal

Der Browser scheint sich mit der Webseite auf ein Encoding der Zeilenenden (oder vielleicht geht es sogar um die Chunks direkt) geeinigt haben und Dein Proxy hat's wohl nicht mitgekriegt. Da der Proxy wohl die Header auswerten will, hat der Parser da versagt, wo das ^M (eigentlich ein Zeilenabschluss für MS-Windows-ASCII-Dateien) vorgefunden worden ist und abgebrochen.

Laut http-rfc ist für den Header RFC 822 gültig, also CRLF der gültige Zeilenumbruch. Mir wär neu, dass sowas ausgehandelt wird.

[nakal]

Vielleicht ist das \0xd als Zeilenabschluss vor dem Header oder der Proxy selbst hat HTTP/1.1 nicht verstanden und den Kram umkodiert.

[Yamagi]

Dokuwiki hatte früher einmal das Problem, dass die CSS-Dateien mit invaliden Zeitangaben im HTTP-Header geschickt wurden. Das führt zu dem von dir genannten Problem, nicht nur in Zusammenarbeit mit Squid, sondern auch mit einigen Browsern. Der Opera war dort der bekannteste Fall. Ich hatte es damals erst selbst repariert, irgendwann wurde es denn auch von offizieller Seite gepatcht. Mag sein, dass das ein Fall noch offen geblieben ist. Kannst du mir einmal den kompletten HTTP-Header geben, falls man den sich mit Suqid irgendwie angeln kann?

Das er print.css nicht findet scheint aber ein Bug im Template zu sein. Ich schreibe es mal auf meine lange, berüchtigte Liste.

[troll]

Schaut mal mit curl -I nach. Das wiki sendet keine chunk-header.
Kanns sein, dass da noch einzusätzlicher Zwangsproxy eines Providers dazwischen ist, der für Verwirrung sorgt?
Ihr könntet per Mail, odie IP austauschen, einen Request zu definierter Zeit abschicken und dann in den logs nachschauen, ob der Request einging - und ob er von der richtigen IP einging.

[nakal]

Ich habe mit telnet nachgeschaut. Es sendet chunked.

GET http://wiki.bsdforen.de/ HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 26 Feb 2009 09:18:53 GMT
Server: Apache/2.2.8 (FreeBSD) mod_ssl/2.2.8 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: DokuWiki=xxx; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-TemplateHeader: monobook
Set-Cookie: DokuWiki=xxx; path=/
Set-Cookie: DokuWiki=xxx; path=/
Set-Cookie: xxx=deleted; expires=Wed, 27-Feb-2008 09:18:53 GMT; path=/
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

260c
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
[...]
</div>

<!-- no cachefile used, caching forbidden -->


1a90
<br/>
[...]
</html>

0

Was mich wundert... ist chunked für HTTP/1.0 überhaupt definiert (er antwortet mir auch in HTTP/1.1)? Ich hab nix im Standard darüber gefunden. Dann, guck Dir mal den Cookie-Wahnsinn an (3 Wiederholungen des gleichen Headers). Und der Expires-Header scheint auch amok zu laufen. So ganz toll ist das da nicht.

Edit, wegen "chunked" (aus RFC 2145, Sektion 2.2):

An implementation of HTTP/x.b sending a message to a recipient whose
version is known to be HTTP/x.a, a < b, MUST NOT depend on the
recipient understanding a header not defined in the specification for
HTTP/x.a. For example, HTTP/1.0 clients cannot be expected to
understand chunked encodings, and so an HTTP/1.1 server must never
send "Transfer-Encoding: chunked" in response to an HTTP/1.0 request.

Es kann doch ein Bug im HTTP-Server sein oder wenigstens im CGI-Skript, das die Antworten generiert.

[troll]

Upps, tatsächlich, via Telnet bekommt man den Header.
IMHO war die Antwort mit HTTP/1.1 OK, wenn der Server halt nix Anderes spricht.
Der Expired-Header für den Cookie ist valide, er ist eine Aufforderung zum Löschen.

Das caching ist aber schon interessant. Mach mal mehrere Aufrufe.

1)
<!-- no cachefile used, caching forbidden -->
<!-- no cachefile used, but created /dokuwiki-db/cache/6/60a83cd3ddbf23506a25691563a348d8.xhtml -->

2)
<!-- no cachefile used, caching forbidden -->
<!-- cachefile /dokuwiki-db/cache/6/60a83cd3ddbf23506a25691563a348d8.xhtml used -->

Allerdings dürfte das nix mit den Chunk-Errors zu tun haben...

[nakal]

Zitat von troll

Upps, tatsächlich, via Telnet bekommt man den Header.
IMHO war die Antwort mit HTTP/1.1 OK, wenn der Server halt nix Anderes spricht.

Ja. Ich glaube die Antwort geht, wenn der Server tatsächlich mehr kann. Aber er darf nicht chunked senden, wenn eine HTTP/1.0-Anfrage gesendet worden ist. Ich denke aber, dass das die PHP-Scripte von dem Wiki erzeugen, weil die Konfiguration fest auf HTTP/1.1 gestellt ist oder sie einfach schlecht sind.

[Olodin]

So, hab jetzt mal mit und ohne proxy getestet:

Ohne Proxy, was ist denn das für ein 25ba da mittendrin?

$ echo -e "GET http://wiki.bsdforen.de HTTP/1.0\n" | nc wiki.bsdforen.de 80 |head -n 20
HTTP/1.1 200 OK
Date: Thu, 26 Feb 2009 19:26:44 GMT
Server: Apache/2.2.8 (FreeBSD) mod_ssl/2.2.8 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: DokuWiki=3e4c9ad60ccc16f3988ff6bb8cd406ce; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-TemplateHeader: monobook
Set-Cookie: DokuWiki=3e4c9ad60ccc16f3988ff6bb8cd406ce; path=/
Set-Cookie: DokuWiki=3e4c9ad60ccc16f3988ff6bb8cd406ce; path=/
Set-Cookie: DWd2cd9fa30e1a25b26b4455485c68ceec=deleted; expires=Wed, 27-Feb-2008 19:26:43 GMT; path=/
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

25ba
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de"
 lang="de" dir="ltr">
        <head>

Mit dem Proxy, der läuft lokal und ist ein Squid aus den Ports auf FreeBSD 7.0:

$ echo -e "GET http://wiki.bsdforen.de HTTP/1.0\n" | nc proxy 8080 |head -n 20
HTTP/1.0 200 OK
Date: Thu, 26 Feb 2009 19:28:24 GMT
Server: Apache/2.2.8 (FreeBSD) mod_ssl/2.2.8 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: DokuWiki=4e6b872cec6eb65b19fbd7b4d705add1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-TemplateHeader: monobook
Set-Cookie: DokuWiki=4e6b872cec6eb65b19fbd7b4d705add1; path=/
Set-Cookie: DokuWiki=4e6b872cec6eb65b19fbd7b4d705add1; path=/
Set-Cookie: DW0614751f914c492e09ceae96e42898bc=deleted; expires=Wed, 27-Feb-2008 19:28:23 GMT; path=/
Content-Type: text/html; charset=utf-8
X-Cache: MISS from proxy
Via: 1.1 proxy:8080 (squid/2.7.STABLE6)
Connection: close

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de"
 lang="de" dir="ltr">