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-compliance Rene 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.