[wiki] anzeigeprob startseite. stylesheet?

Olodin

Reading User
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:
Code:
<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! ;)
 

Anhänge

  • ScreenCapture[23].jpg
    ScreenCapture[23].jpg
    141,4 KB · Aufrufe: 680
  • ScreenCapture[24].jpg
    ScreenCapture[24].jpg
    90,9 KB · Aufrufe: 658
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.
 
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/monobook/common/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/monobook/common/commonPrint.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.
 
Zuletzt bearbeitet:
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.
 
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.
 
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)
Code:
<!-- 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:
Code:
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.
 
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).
 
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.
 
Vielleicht ist das \0xd als Zeilenabschluss vor dem Header oder der Proxy selbst hat HTTP/1.1 nicht verstanden und den Kram umkodiert.
 
Zuletzt bearbeitet:
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. :)
 
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.
 
Ich habe mit telnet nachgeschaut. Es sendet chunked.

Code:
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.
 
Zuletzt bearbeitet:
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...
 
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.
 
mehr tests mit und ohne proxy

So, hab jetzt mal mit und ohne proxy getestet:

Ohne Proxy, was ist denn das für ein 25ba da mittendrin?
Code:
$ 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:
Code:
$ 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">
 
Das taucht immer wieder mal auf. Ich hab's schon bei mehreren DokuWikis gesehen. Es ist also meiner Meinung nach kein lokales Problem.
 
Ich kämpfe dann mal mit meinem squid, vielleicht lässt er sich ja überreden, die Seite richtig anzuzeigen.

Ansonsten gibts nen Bug fürs Dokuwiki.
 
Bin gerade wieder am gucken: ist es vielleicht ein Template Problem?

Diese Seite funktioniert auch mit Proxy: http://wiki.bsdforen.de/navigation

Und auch die Seite vom monobook Template zeigt keinerlei Probleme mit Proxy.

Auf der oben verlinkten Navigations-Seite gibts ja den Button zum Wechsel auf das Dokubook template: klappt das bei euch? Bekomme nur eine Seite ohne Stylesheet (mit oder ohne Proxy).
 
Sodele, endlich mal wieder Zeit gefunden, nach dem Prob zu schauen.

Mal ins Blaue von Squid 2.7 auf Version 3.0.STABLE18 aktualisiert und tada: jetzt gehts endlich auch mit dem lieben Proxy :)
 
Zurück
Oben