HTTP Parser Klasse



  • Moin,

    macht es Sinn eine (bzw. mehrere) eigene Klasse zum Parsen von HTT-Protokollen zu entwickeln? Anforderungen wären: Parsen von HTT-Protokollen, Bereitstellung eines Event-Handlers, Art von Responder.

    Bsp Parser:
    HTTP wird übergeben -> parsing -> Auf Wunsch: Auslösen bzw. Eintragen eines Events

    Bsp Responder:
    Gewünschte Werte werden übergeben (Zeit, Art, Inhalt, etc.) -> HTTP wird erstellt -> ab zum Parser -> korrekt? dann alles gut

    Bsp Event Handler:
    Parser übergibt Event -> Handler löst Trigger aus ODER füllt Warteschleife, die dann "manuell" abgearbeitet werden muss

    Ich frage, ob das Sinn macht, da ich mir nicht sicher bin, ob es sowas bereits gibt. Die vorhandenen HTTP-Parser/-Wrapper/-whatever scheinen alle sehr spezifisch zu sein (wie dieser es dann auch wäre). Den Standard zu implementieren ist aber widerum echter Aufwand, so dass ich auf eure Meinungen gespannt bin, ob das gut umsetzbar ist (besonders in Bezug auf das Implementieren des Standards) oder das schonmal jemand in irgendeiner Form gemacht hat bzw. Libs/Wrapper/Parser kennt, die sowas eigentlich auch können.



  • Naja, sobald du die EBNF von HTTP in einen Parser gegossen hast, wird's eigentlich ziemlich langweilig: das riesige RFC studieren und die ganzen kleinen Extras und Feinheiten, die es in HTTP gibt (und die kaum einer nutzt) implementieren.
    Hinzu kommt, dass es schon hunderte HTTP-Implemenierungen in X Programmiersprachen gibt.
    Wenn es nur darum geht, etwas zu lernen, würde ich mir was spannenderes suchen als das alte HTTP und ein RFC abzuarbeiten.



  • Fake oder Echt schrieb:

    Anforderungen wären: Parsen von HTT-Protokollen, Bereitstellung eines Event-Handlers, Art von Responder.

    Eine Liste von Begriffen, die mir gerade eingefallen sind, wäre: Baum, Bereitstellung von Apfel, Typ der Eiskugeln.

    Was willst du überhaupt erreichen?

    Fake oder Echt schrieb:

    Bsp Parser:
    HTTP wird übergeben -> parsing -> Auf Wunsch: Auslösen bzw. Eintragen eines Events

    Bsp Responder:
    Gewünschte Werte werden übergeben (Zeit, Art, Inhalt, etc.) -> HTTP wird erstellt -> ab zum Parser -> korrekt? dann alles gut

    Bsp Event Handler:
    Parser übergibt Event -> Handler löst Trigger aus ODER füllt Warteschleife, die dann "manuell" abgearbeitet werden muss

    Keine Ahnung was du mir damit sagen möchtest.

    Fake oder Echt schrieb:

    Ich frage, ob das Sinn macht, da ich mir nicht sicher bin, ob es sowas bereits gibt.

    Was ist "sowas"? Webserver gibt es (nginx, Apache). HTTP-Bibliotheken für C++ gibt es eher nicht.

    Fake oder Echt schrieb:

    Die vorhandenen HTTP-Parser/-Wrapper/-whatever scheinen alle sehr spezifisch zu sein (wie dieser es dann auch wäre).

    Der Ablauf ist so:
    - Hey, wir brauchen einen HTTP-Server. Gibt es da eine Bibliothek?
    - Oh, es gibt keine. Muss ich wohl selber schreiben.
    - Ich brauche für meinen Anwendungsfall nur ganz wenig von HTTP 1.1. Die Bibliothek würde anderen nicht viel nützen.
    (- Ich bin zu doof eine Bibliothek generisch zu schreiben, also komme ich gar nicht erst auf die Idee.)
    -> Yet another custom, incomplete and non-reusable HTTP server implementation.

    Fake oder Echt schrieb:

    Den Standard zu implementieren ist aber widerum echter Aufwand, so dass ich auf eure Meinungen gespannt bin, ob das gut umsetzbar ist (besonders in Bezug auf das Implementieren des Standards) oder das schonmal jemand in irgendeiner Form gemacht hat bzw. Libs/Wrapper/Parser kennt, die sowas eigentlich auch können.

    Identifiziere die Teilmenge, die du benötigst. Wenn die klein ist, implementiere HTTP selbst. Das ist die schnellste Lösung.



  • HTTP - Hyper Text Transfer Protocol
    HTML - Hyper Text Modelling Language



  • Tim06TR - Was will er uns wohl damit sagen?
    (Tip: HTTP und HTML wurde hier nie verwechselt.)



  • Tim06TR schrieb:

    HTML - Hyper Text ModellingMarkup Language



  • TyRoXx schrieb:

    Was ist "sowas"? Webserver gibt es (nginx, Apache). HTTP-Bibliotheken für C++ gibt es eher nicht.

    libcurl, libneon, cpp-netlib, POCO?



  • hustbaer schrieb:

    libcurl, libneon, cpp-netlib, POCO?

    curl und neon sind nur Client.
    cpp-netlib ist zu unausgereift für ernsthafte Verwendung.
    POCO ist kein modernes C++ und bringt viel anderen Müll mit, den man nicht braucht. Gleichzeitig ist der HTTPServer nicht besonders flexibel.



  • Casablanca von Microsoft



  • hustbaer schrieb:

    Tim06TR - Was will er uns wohl damit sagen?
    (Tip: HTTP und HTML wurde hier nie verwechselt.)

    Ich hatte den Post nicht gründlich genug gelesen. und mir kam nicht in den Sinn, dass man auch über das Parsen der Header reden kann.

    POCO ist kein modernes C++ und bringt viel anderen Müll mit, den man nicht braucht. Gleichzeitig ist der HTTPServer nicht besonders flexibel.

    POCO ist aber einfach und der Server ist zügig geschrieben... Wenn man das als Argument gelten lässt



  • rest sdk schrieb:

    Casablanca von Microsoft

    Wow, ich hatte noch gar nicht auf dem Schirm, dass Microsoft tatsächlich eine Bibliothek für nicht-nur-Windows veröffentlicht. Werde ich mir mal ansehen.

    Tim06TR schrieb:

    POCO ist kein modernes C++ und bringt viel anderen Müll mit, den man nicht braucht. Gleichzeitig ist der HTTPServer nicht besonders flexibel.

    POCO ist aber einfach und der Server ist zügig geschrieben... Wenn man das als Argument gelten lässt

    Kann man wohl zur Not verwenden.



  • TyRoXx schrieb:

    hustbaer schrieb:

    libcurl, libneon, cpp-netlib, POCO?

    curl und neon sind nur Client.

    Oops, ja, stimmt.
    Ich muss wohl etwas zerstreut sein. Hatte schon gar nicht mehr daran gedacht dass der OP ja die Serverseite braucht.

    TyRoXx schrieb:

    cpp-netlib ist zu unausgereift für ernsthafte Verwendung.

    Hm. Sieht aber vielversprechend aus. Auf jeden Fall würde ich es erstmal damit versuchen, bevor ich was ganz eigenes schreibe. Zur Not kann man die fehlenden bzw. fehlerhaften Teile ja selbst reinhacken/ausbessern.

    TyRoXx schrieb:

    POCO ist kein modernes C++ und bringt viel anderen Müll mit, den man nicht braucht. Gleichzeitig ist der HTTPServer nicht besonders flexibel.

    Ja ich weiss, ich bin selbst kein POCO Fan. Ist aber recht ausgereift und hat eben nen HTTP Server.



  • Nette Diskussion 👍
    POCO lehne ich einfach anhand eurer Meinungen ab. Unflexibler Server + jede Menge Overload ist da mein Ausschlußkriterium.

    cpp-netlib und Casablanca klingen gut, wie flexibel da mit HTTP gearbeitet werden kann, werde ich mir mal zu Gemüte führen.

    Ziel des Projektes ist es nicht, etwas zu lernen (auch wenn das natürlich immer ein netter Nebeneffekt ist). Mal abgesehen davon, dass die Implementierung der BNF aus meiner Sicht langweiliger ist, als die Feinheiten umzusetzen, aber ist ja Geschmackssache 😉
    Stattdessen soll das HTTP als Verpackung für ein eigenes kleines Protokoll dienen, daher die Überlegung, dass direkt selbst umzusetzen. Zweifel kamen mir, da die der Client sehr wahrscheinlich web-basiert sein wird, daher könnte ich nicht einfach irgendwas implementieren, sondern müsste wenigstens so viel bereitstellen, dass alle gängigen Browser das Protokoll durchwinken.



  • Du könntest dir auch überlegen, FastCgi einzusetzen und einen richtigen Webserver davorzuschalten.
    Und wenn du Windows benutzt, gibts da einen integrierten Webserver, den du nutzen könntest.



  • Du könntest dir auch noch folgende ansehen:

    http://www.tntnet.org/ (von "unserem" tntnet)
    http://www.webtoolkit.eu/wt

    Beides sind C++ web application server/toolkits. Also nicht genau das wonach du gefragt hast, aber sie liessen sich vermutlich für deine Zwecke verwenden/adaptieren.

    ps: Hier gibt's ne vollständigere Liste:
    http://en.wikipedia.org/wiki/Comparison_of_application_servers#C.2B.2B



  • Mechanics schrieb:

    Du könntest dir auch überlegen, FastCgi einzusetzen und einen richtigen Webserver davorzuschalten.
    Und wenn du Windows benutzt, gibts da einen integrierten Webserver, den du nutzen könntest.

    Auf Windows gäbe es dann auch noch die http.sys .
    Mit C# ist die Verwendung der http.sys ziemlich einfach ( HttpListener Klasse), und der nötige C++/CLI Gluecode um die Requests in einer C++ DLL zu bearbeiten ist auch nicht wirklich sehr schwierig/aufwendig.



  • Sehr schön, vielen Dank.

    @Mechanics: FastCGI in Verbindung mit IIS (denke mal, dass du IIS als Webserver meintest?) sounds utterly reasonable, besonders, da als OS auch Windows Server 2008 zur Verfügung steht.

    @hustbaer: Sowohl tntnet, als auch tntdb sehen echt gut aus. Ob tntnet das Richtige ist, werde ich sehen, wenn ich mich etwas eingelesen habe. Aber alleine die LGPL ist schon ein großer Pluspunkt. Wenn tntdb "ordentlich was her macht", könnte das als SQL-Wrapper fürs Projekt herhalten (sieht erstmal bequemer aus, als SQLite).
    Eine C# Komponente in einer C++ DLL zu kapseln, klingt für mich eher gruselig, auch wenn es sicherlich eine sehr effiziente Lösung sein kann.

    Sind auf jeden Fall sehr gute Alternativen im Vergleich zum Eigenpfusch (bin natürlich für noch mehr Ideen/Erfahrungen offen) und ich werde mich dann alsbald zumindest konzeptionell mal genauer mit den Möglichkeiten beschäftigen 👍



  • Fake oder Echt schrieb:

    Eine C# Komponente in einer C++ DLL zu kapseln, klingt für mich eher gruselig, auch wenn es sicherlich eine sehr effiziente Lösung sein kann.

    Jo, muss man nicht unbedingt machen wenn's auch anders geht 🙂

    Ich wollte es trotzdem erwähnen ...
    weil es eine Lösung ist die man relativ schnell auf die Beine gestellt hat wenn man C#, C++ und C++/CLI kann,
    weil es sehr performant läuft und
    weil es recht mächtig ist.
    Und zumindest den Ruf hat sehr stabil und zuverlässig zu sein.

    Letzteres kann ich allerdings selbst nicht beurteilen, da das Projekt wo ich genau auf diese Art einen HTTP Server eingebunden habe noch keiner Attacke oder vergleichbarem Test standhalten musste. (Nachdem der Server in dem Projekt nur lokal erreichbar ist, ist das für uns aber auch kein wichtiger Punkt.)



  • Oops, übersehen:

    www.tntnet.org/faq.html schrieb:

    1.6 - Does tntnet run under Windows?

    No. Tntnet do not run under Windows. Until now nobody was willing to port tntnet to Windows. If someone want to port it to Windows, we'll love to support it.



  • hustbaer schrieb:

    Oops, übersehen:

    www.tntnet.org/faq.html schrieb:

    1.6 - Does tntnet run under Windows?

    No. Tntnet do not run under Windows. Until now nobody was willing to port tntnet to Windows. If someone want to port it to Windows, we'll love to support it.

    Wieso übersehen? Hier wurde doch nicht nach Windows gefragt. Verwendet denn noch jemand dieses Betriebssystem 😉 ?

    Den httpparser kann man natürlich aus tntnet abschauen oder extrahieren, wenn man will.

    Übrigens haben die cxxtools auch einen http Server. Er wird für xmlrpc und jsonrpc verwendet. Ein Freund arbeitet gerade an einer Portierung auf cygwin.


Anmelden zum Antworten