Guten Morgen,
ich programmiere gerade einen kleinen Webserver. Eigentlich funktioniert
auch alles so weit... (eigentlich!) Aber ein paar Problemchen gibts
trotzdem noch:
- Jede 2. Seitenanfrage liefert im Browser ein "Seite konnte nicht
gefunden werden..."-Fehler. Nach einem (oder mehreren) Refreshs
funktionierts dann.
- Firefox weigert sich komplett die Seiten zu laden, mit Chrome
hingegen klappt's sehr gut.
- usw.
Nun ist die Frage, wie ich den Problemen auf die Schliche komme. Mit dem
Debugger klappt's nicht wirklich gut. Z.B. kommt es häufig vor, dass ich
eine Seite aufrufe, und der der Browser meint die Seite wäre nicht
erreichbar. Laut Debugger geht aber nicht mal HTTP Request ein...
Aber ich vermute mal, dass ich auch viele HTTP-Protokoll-spezifische
Bugs eingebaut habe ;-) (Ungültige Header oder so)
Daher wäre es eine große Hilfe, wenn es eine Art Webserver-Tester gäbe,
der einfach mal alles abklappert, was das HTTP-Protokoll zu bieten hat.
Die Antworten und Timings sollen dabei geloggt und ausgewertet werden.
Am Ende könnte dann ein Test-report anzeigen, ob sich der Webserver so
verhält wie er sollte, oder ob/welche Probleme es gibt.
Gibt es so ein Tool?
Hallo,
wenn es 'nur' um die Funktionalität des Webservers geht, dann reichen
die beiden wichtigsten Logfiles aus. access.log und error.log
Was sagen den deine Logs zu den Problemen? Was fehlt dir an
Informationen in den beiden Logfiles?
Grüße aus Berlin
Quizbart schrieb:> ich programmiere gerade einen kleinen Webserver
Aus Spaß an der Freude? Da gibt es doch wohl schon für jeden Geschmack
etwas...
Quizbart schrieb:> und der der Browser meint die Seite wäre nicht erreichbar
Dann ist wohl einfach der Link falsch, oder dein Socket nicht offen oder
du implementierst das keep-alive falsch...
Quizbart schrieb:> Aber ich vermute mal, dass ich auch viele HTTP-Protokoll-spezifische> Bugs eingebaut habe
Aha... all das sollte aber nicht zu einem 404 o.ä. Fehler führen.
Quizbart schrieb:> wenn es eine Art Webserver-Tester gäbe
Mach doch einfach mal einen Socket zum Server auf und lass dir mittracen
was da so alles drüber läuft...
Ansonsten:
http://stackoverflow.com/questions/6100848/a-test-for-http-1-1-complianceRene Schube schrieb:> Was sagen den deine Logs zu den Problemen?
Wenn er eine Apache Webserver nutzen würde hätte er wohl kaum diese
Probleme...
Warum machen die 'großen' Webserver so etwas? Weil es u.a. die
Fehlersuche erheblich vereinfacht.
Also mach für das debuggen einen Ausgang, als Stream, aufs Display, wie
auch immer. Guck wie es z.B. bei Apache gemacht wird.
Was kommt den bei deinem Server an? Wie sehen die Anfragen aus und wie
unterscheiden sich die Anfragen von Firefox und Chrome?
Wie sieht der Request-Header aus?
Läubi .. schrieb:> Wenn er eine Apache Webserver nutzen würde hätte er wohl kaum diese> Probleme...
Da der Server auf einem C läuft, ist das wohl keine Option.
Läubi .. schrieb:> Dann ist wohl einfach der Link falsch, oder dein Socket nicht offen oder> du implementierst das keep-alive falsch...
Der Link ist in Ordnung. Nach mehrmaligem Refresh lädt die Seite ja
dann. Da das ganze ganze auch beim "Erstaufruf" nach frischem
Systemstart auftritt, wird's auch nichts mit einem Keep-Alive zu tun
haben. Der Socket sollte (laut Debugger) ebenfalls offen sein udn auf
eine Verbindung warten.
Läubi .. schrieb:> Aha... all das sollte aber nicht zu einem 404 o.ä. Fehler führen.
OK, da kenn ich micht jetzt nicht so gut mit aus...
Läubi .. schrieb:> Mach doch einfach mal einen Socket zum Server auf und lass dir mittracen> was da so alles drüber läuft...
Gute Idee. Ich werde nachher mal den Wireshark installieren. Der
beherrscht ja auch diverse Protokolle (sicher auch HTTP).
Läubi .. schrieb:> Wenn er eine Apache Webserver nutzen würde hätte er wohl kaum diese> Probleme...
Man muss ja nicht Apache benutzen um Logfiles zu haben. Ich würde mir
bei so einem Programm immer irgend eine Ausgabemöglichkeit einbauen. Und
bei den Jungs von Apache kann man gut abgucken, die haben die Sachen
immerhin richtig gut umgesetzt.
Quizbart schrieb:> Da der Server auf einem C läuft,
Was zwar m.W. nirgends steht, aber möglich ist. Nur ist dann neben dem
Webserver vielleicht auch der TCP/IP-Stack nicht voll verlässlich.
Quizbart schrieb:> Nach mehrmaligem Refresh lädt die Seite ja dann
Dann schau doch erstmal mit einem eigenem Client (nicht wireshark)
oder von miraus Telnet im RAW Modus ob du wenigstens die Header korrekt
sendest (\r\n, letzte Zeile mit \r\n\r\n, korrektes Content-Length fals
keep-alive genutzt wird etc....).
Für erste Tests ist es auch immer gut mal mit HTTP1.0 zu starten.
Quizbart schrieb:> Da der Server auf einem C läuft
??? Meinst du µC ??? Da gibt es ja nun auch verschiedene "Stärkeklassen"
und nun wäre es dann wirklich mal an der Zeit die genaue Systemumgebung
zu nennen. Auch hier gibt es 100te fertiger und funktionierender
Lösungen auf denen man aufbauen kann...
A. K. schrieb:> Was zwar m.W. nirgends steht, aber möglich ist. Nur ist dann neben dem> Webserver vielleicht auch der TCP/IP-Stack nicht voll verlässlich.
Ich meinte natürlich µC (das µ ist wohl verloren gegangen). Als
TCP/IP-Stack kommt lwip zum Einsatz. Wie ich allerdings gerade gelesen
habe, handelt es sich dabei um eine Beta. Argh!
Könnte also tatsächlich daran liegen...
Ich werde mal die Firmware des µC eine Version zurückschrauben (da ist
dann ein stable Build des lwip drin). Vielleicht behebt das ja schon
einige der Probleme. danke für die Idee ;-)
wget oder curl ist in so einem Fall immer ganz hilfreich.
Trace kann man dann mit Wireshark erstellen und auswerten.
Man kann auch auf dem Webserver im uC tracen, welche Anfrage
er erhält bzw. welche Antworten er sendet, aber dies
beeinflusst dann meist das Timing.
Quizbart schrieb:> Ich werde mal die Firmware des µC eine Version zurückschrauben (da ist> dann ein stable Build des lwip drin). Vielleicht behebt das ja schon> einige der Probleme.
Ist dies so zu deuten, dass du noch keine Ahnung hast,
was intern im Programm abläuft?
Das macht die Fehlersuche dann natürlich
etwas schwer. Erstelle mal einen Wireshark Trace
von einem fehlgeschlagenen einzelnen wget Aufruf
und lade ihn irgendwo im Internet hoch (mit Link hier im Thread).
Ist dies eine private Spielerei oder soll etwas
professionelles dabei raus kommen?
Herbert schrieb:> Ist dies eine private Spielerei oder soll etwas> professionelles dabei raus kommen?
Keine Angst, ist eine private Spielerei.
Ich werd's nicht auf die Menschheit loslassen ;-)
Herbert schrieb:> Ist dies so zu deuten, dass du noch keine Ahnung hast,> was intern im Programm abläuft?
So würde ich das nicht sagen. ich setzte auf dem TCP/IP-Stack auf, und
habe dort so gut es ging das HTTP-Protokoll implementiert. Unterhalb der
TCP/IP-Ebene verlasse ich mich allerdings auf lwip (ich bin einfach mal
davon ausgegangen, dass das funktioniert).
A. K. schrieb:> Hast du überhaupt schon einmal mit Wireshark reingerochen?
Bisher nicht.
Das Problem ist ja, dass ich Fehler in der Kommunikation nicht unbedingt
erkennen würde, wenn ich sie sähe. Wenn z.B. ein HTTP Header nicht ganz
so aussieht, wie der Browser ihn erwartet, eine Antwort zu spät kommt,
oder oder oder...
Daher hatte ich gehofft, dass es ein Tool gibt, was sowas automatisch
untersucht und "menschenlesbar" auswertet.
Ich werd's aber nachher auf jeden Fall mal mit Wireshark probieren,
vielleicht fällt mir doch was auf.
PS: Ich hab mir jetzt noch mal die Fehlermeldung des Browsers
angeschaut: Dieser meldet einfach nur "Serverfehler". Ist also nicht
wirklich hilfreich...
Quizbart schrieb:> Das Problem ist ja, dass ich Fehler in der Kommunikation nicht unbedingt> erkennen würde, wenn ich sie sähe.
Da dein Webserver nicht der einzige auf der grossen weiten Welt ist,
stehen dir ausreichend Vergleichsexemplare zur Verfügung. Ausserdem
können die Leutchens hier im Forum mit qualifizierteren Aussagen als
"geht nicht" auch mehr anfangen.
Quizbart schrieb:> Serverfehler
ist doch aber nicht
Quizbart schrieb:> Seite konnte nicht gefunden werden...
Hol dir für FF mal FireBug und schau dir da den Netzwerkverkehr an.
Quizbart schrieb:> Das Problem ist ja, dass ich Fehler in der Kommunikation nicht unbedingt> erkennen würde, wenn ich sie sähe
Das ist schlecht --> back to the roots und Doku lesen... oder einfach
mal von einer Funktionierenden Verbindung (-> FireBug!) abschauen
Quizbart schrieb:> ein HTTP Header nicht ganz so aussieht, wie der Browser ihn erwartet
s.o. es gibt nicht so wahnsinnig viele header am Anfang als man das
nicht verstehen könnte. Mit HTTP 1.0 sind es fast gar keine mehr...
Quizbart schrieb:> eine Antwort zu spät kommt
Ein Browser hat sehr lange timeouts... sollte für Tests keine Rolle
spielen, außerdem sieht man das auch in FireBug.
Läubi .. schrieb:> die Header korrekt sendest (\r\n, letzte Zeile mit \r\n\r\n
Da hast du voll ins Schwarze getroffen, hier mache ich definitiv noch
was falsch. Da es aber manchmal funktioniert kann das ja eigentlich
nicht das Problem sein.
Läubi .. schrieb:> Hol dir für FF mal FireBug und schau dir da den Netzwerkverkehr an.
Kannte ich noch nicht. -> Werde ich machen!
Dann vielen Dank euch allen für die schnelle Hilfe. Ich denke jetzt habe
ich reichlich Anregungen was ich verbessern könnte. Und eure Vorschläge
bezüglich der Analyse-Ansätze und Tools werden sicherlich auch
weiterhelfen.
Sollte das wider Erwarten nicht zu einer Lösung führen, wende ich mich
nochmal an auch (dann natürlich auch mit ein paar mehr Details).
Quizbart schrieb:> Da es aber manchmal funktioniert
Manchmal reicht nicht. Auf diese Weise kann der Client den Request nicht
korrekt abarbeiten und ggf. hängt irgendeine Statemachine.
