Ingebedde HTTP server

[Verwijderd]

Yow,

Voor het softwarepakket dat ik momenteel ontwikkel heb ik een configuratiepaneel nodig. Ik dacht er aan een ingebedde HTTP server te gebruiken. De gebruiker opent dus een browser waarin een HTTP-pagina getoond wordt met alle configuratie-opties van het softwarepakket.

Dit heeft als voordeel dat het op meerdere platformen kan werken, interactief kan zijn, en de configuratie ook vanaf een ander systeem geregeld kan regelen. En dit alles hopelijk zonder veel programmeerwerk...

Ik heb echter geen ervaring met deze technologieën en vroeg mij af of hier iemand meer weet over ingebedde HTTP servers en/of dit soort webpagina's als configuratiescherm. Google toont een ruim aanbod aan open-source webservers maar uiteraard wil ik er eentje dat stabiel is, de nodige features heeft, en vooral klein is. Propere C/C++ code is ook een grote plus.

Alle hulp zeer gewaardeerd!

Nicolas

[Devion]

Een HTTP server is niks meer dan een text parser met wat logica. TCP poort laten luisteren, filteren wat de client browser wil hebben (GET / HTTP/1.0 etc). Daarna terug sturen saampjes met een simpele HTML header and voila!.

In principe heb je dus niet veel meer nodig dan een TCP listenener en een streamreader (Ik ga ervanuit dat je ook graag wat images wilt terug sturen )

[Niemand_Anders]

Enerzijds geef je aan geen ervaring te hebben met HTTP technologie, maar je programma moet wel stabiel zijn. Een beetje tegenstrijdig dus ;-)

Mocht je toch per se HTTP willen gebruiken, dan raad ik je AppWeb aan. Het is geschreven in C++ en gereleased als open source. Het is een embedded HTTP server met support voor HTTP 1.1 inclusief SSL en CGI. Ook de performance is zeer goed.

Een andere oplossing is gewoon een statische HTML page (de configuratie) en het parsen en verwerken van de HTTP post. Dat is redelijk simpel met alleen wat socket programming.

[leuk_he]

de nodige features heeft, en vooral klein is.

Deze 2 sluiten elkaar dus uit. Belangrijk is dus te bepalen welke feature je webserver nodig heeft. Wellicht gaat het zoeken ook makkelijker als je dit weet te definiëren.

Licentie is wellicht ook van belang (bsd,gpl,payware)

[deadinspace]

Verwijderd schreef op donderdag 17 januari 2008 @ 15:28:
... een HTTP-pagina ...

Devion schreef op donderdag 17 januari 2008 @ 15:47:
... HTML header ...

Volgensmij draaien jullie wat om

Devion schreef op donderdag 17 januari 2008 @ 15:47:
Een HTTP server is niks meer dan een text parser met wat logica. TCP poort laten luisteren, filteren wat de client browser wil hebben (GET / HTTP/1.0 etc). Daarna terug sturen saampjes met een simpele HTML header and voila!.

Ik raad af om zelf een HTTP server te schrijven, tenzij je wel hele specifieke wensen hebt. Anders loop je het risico dat je maar half aan de HTTP RFCs voldoet, waardoor het raar kan gaan doen icm software (browsers bv, maar ook proxies) waarmee je toevallig niet getest hebt.

[Verwijderd]

Devion schreef op donderdag 17 januari 2008 @ 15:47:
In principe heb je dus niet veel meer nodig dan een TCP listenener...

De focus is op het creëren van een interactief configuratiescherm. Daarom gebruik ik het liefst bestaande oplossingen voor de communicatie met de webpagina. Heb je eventueel ervaring hiermee?

De webpagina moet een aantal radiobuttons, checkboxes, en drop-down lists bevatten. Elke verandering zou liefst onmiddelijk naar het softwarepakket gestuurd moeten worden zodat die interactief zijn gedrag kan aanpassen. Daarnaast moet de configuratie ook op schijf opgeslagen worden...

[Verwijderd]

Niemand_Anders schreef op donderdag 17 januari 2008 @ 15:51:
Enerzijds geef je aan geen ervaring te hebben met HTTP technologie, maar je programma moet wel stabiel zijn. Een beetje tegenstrijdig dus ;-)

Waarom? Trouwens, ik heb wel ettelijke cursussen over netwerken gehad, ik heb er gewoon geen praktische ervaring mee iets zoals dit op te zetten. Mij specialiteit ligt bij 3D rendering en (dynamische) codegeneratie. Aan programmeerervaring geen gebrek hoor.

Mocht je toch per se HTTP willen gebruiken, dan raad ik je AppWeb aan. Het is geschreven in C++ en gereleased als open source. Het is een embedded HTTP server met support voor HTTP 1.1 inclusief SSL en CGI. Ook de performance is zeer goed.

Het moet niet per se HTTP zijn, ik dacht gewoon dat dit het begin vormde van de aanpak. AppWeb ziet er zeer interessant uit. Bedankt voor de link!

[Janoz]

Misschien moet je je anders eerst even in het hele http en html gebeuren verdiepen. Zelf een http server schrijven met beperkte mogelijkheden is heel simpel. Voor een eigen projectje heb ik dat ook gedaan. De feature lijst die je daar beschrijft heeft helemaal niks met je httpserver te maken, maar kan allemaal door de browser met juist html afgehandeld worden. Het enige wat je server moet kunnen is de html van de schermen opleveren en (ajax-)requests af kunnen handelen om de veranderingen door te voeren of op te slaan.

Ikzelf zou het gewoon zelf schrijven. Het is niks meer dan een serversocket laten luisteren, zodra hier een verbinding op binnen komt deze uitlezen en parsen (erg simpel, beschrijving staat wel in het RFC) en vervolgens je html terug sturen.

[AtleX]

Het nadeel van zelf een webservertje schrijven is dat je met ontzettend veel dingen rekening moet houden. Dingen als character set, security, HTTP protocol (en violations door UA's), etc. komen er allemaal bij kijken. Wat gebeurt er als de client een loze verbinding opent? Moeten meerdere clients tegelijk mogelijk zijn (threading)? Moet er gelogged worden (race conditions, Producer/Consumer kan hier een oplossing zijn)? Access control (HTTP/401)? Voor 90% van de applicaties is zelf een embedded HTTP server schrijven overkill, en kan je beter zoeken naar een component dat het voor je af kan handelen.

[Verwijderd]

leuk_he schreef op donderdag 17 januari 2008 @ 15:51:
Deze 2 sluiten elkaar dus uit.

Waarom? Ik bedoel gewoon dat het moet ondersteunen wat ik nodig heb voor zo'n configuratiescherm te realiseren, maar niet (veel) meer dan dat.

Belangrijk is dus te bepalen welke feature je webserver nodig heeft. Wellicht gaat het zoeken ook makkelijker als je dit weet te definiëren.

Daarvoor post ik hier juist... Soit, veiligheid is bijvoorbeeld helemaal niet nodig. Meestal zal het op hetzelfde systeem gebruikt worden, of binnen dezelfde LAN. Anderzijds wil ik op zo eenvoud mogelijke wijze de configuratie-elementen op de webpagina aan mijn C++ variabelen 'linken'.

Licentie is wellicht ook van belang (bsd,gpl,payware)

Liefst BSD of LGPL of dergelijke.

[TeeDee]

Even een rare kronkel hoor maar:

Kan je niet bij je eigen gemaakte software pakket gewoon iets van een ConfigEditor bouwen? Laat deze een .config file (of wat dan ook) wegschrijven en lees dit in bij het opstarten van je pakket. Ben je er ook en hoef je niet lastig te doen met een HTTP variant.

Platformonafhankelijkheid maakt geen kont uit omdat het toch al in jouw pakket draait.

[Verwijderd]

TeeDee schreef op donderdag 17 januari 2008 @ 17:30:
Kan je niet bij je eigen gemaakte software pakket gewoon iets van een ConfigEditor bouwen? Laat deze een .config file (of wat dan ook) wegschrijven en lees dit in bij het opstarten van je pakket.

Ik heb reeds een config file. Maar dit werkt niet vlot. De tool is vooral bedoeld voor mijzelf tijdens het debuggen, en voor andere developers die het softwarepakket willen integeren en snel het gedrag willen aanpassen. De applicatie draait ook soms fullscreen, zodat het configuratiepaneel best remote toegankelijk kan zijn (doch binnen een LAN). Ik ken een applicatie (in ontwikkeling) die dit doet via een webpagina, en het werkt zeer prettig.

[leuk_he]

Verwijderd schreef op donderdag 17 januari 2008 @ 17:05:
[...]

Waarom? Ik bedoel gewoon dat het moet ondersteunen wat ik nodig heb voor zo'n configuratiescherm te realiseren, maar niet (veel) meer dan dat.

Klein en veel features sluiten elkaar uit. Je zult een middenweg tussen die 2 zoeken. Dat voel je zelf ook wel aan, maar veel hint wat die tussenweg is is me nog niet duidelijk.

klein op een embeded device is wat anders als klein op een moderne pc.

[Janoz]

AtleX schreef op donderdag 17 januari 2008 @ 17:02:
Het nadeel van zelf een webservertje schrijven is dat je met ontzettend veel dingen rekening moet houden. Dingen als character set, security, HTTP protocol (en violations door UA's), etc. komen er allemaal bij kijken. Wat gebeurt er als de client een loze verbinding opent? Moeten meerdere clients tegelijk mogelijk zijn (threading)? Moet er gelogged worden (race conditions, Producer/Consumer kan hier een oplossing zijn)? Access control (HTTP/401)? Voor 90% van de applicaties is zelf een embedded HTTP server schrijven overkill, en kan je beter zoeken naar een component dat het voor je af kan handelen.

Dat valt echt heel erg mee. Het http protocol is enorm simpel en je kunt een enorm deel hiervan compleet negeren (incl de headers in het request). Charactersets heb je compleet in eigen hand en hiervoor kun je dus gewoon 1 kiezen die je terugstuurt. Loze verbindingen vang je simpel op met een timeout of je stuurt een bad request terug wanneer je niks van het request kunt maken. Threading is niet erg lastig te implementeren en ook loggen is natuurlijk gewoon wat tekst wegschrijven naar een bestandje. Race condities en producer consumer problemen zijn daarbij niet aan de orde.

Tot slot de access control. Dit kun je implementeren, maar je zou dit ook gewoon op kunnen lossen met een proxy of wat dan ook. Het gaat hier immers om een webinterface voor een applicatie, niet een complete webserver die door iedereen bereikbaar zou moeten zijn. Mijn implementatie (die ik picohttpd heb genoemd) had ik klaar in een 1 class van enkele tientallen regels en daarbij had ik al een vorm van inloggen, ipwhitelist en sessies geimplementeerd voor de achterliggende applicatie.

[farlane]

Je zou bijvoorbeeld naar httpd, thttp of Boa kunnen kijken oid. Ligt een beetje aan je platform

Httpd was geloof ik 400 regels code, maar dan heb je wel alleen een basic server, geen CGI.

[ Voor 32% gewijzigd door farlane op 17-01-2008 18:57 ]

[Verwijderd]

leuk_he schreef op donderdag 17 januari 2008 @ 18:27:
Klein en veel features sluiten elkaar uit.

Dat hangt ervan af of het de features zijn die je wil of niet. Een bibliotheek van een megabyte is klein als je al z'n functionaliteit gebruikt, maar gigantisch als je er slechts één functie van nodig hebt. Ik wil dus simpelweg iets dat min of meer afgestemd is op mijn noden, niet de serversoftware van Google.

Dat voel je zelf ook wel aan, maar veel hint wat die tussenweg is is me nog niet duidelijk.

Dan kan je mij niet verder helpen, want ik heb al uitvoerig genoeg uitgelegd wat ik wil bereiken.

[needless to say]

@c0d1f1ed: je kent mijn mening hierover . Ik zou snel zelf een basis-HTTP-server bouwen. Dit valt trouwens erg makkelijk te debuggen. Gewoon wireshark openhouden en zien hoe je HTTP-server reageert op browser-aanvragen.

Het protocol is zo eenvoudig dat het waarschijnlijk minder lang duurt om het te programmeren dan om een bestaand pakket te zoeken, te bestuderen en in te bouwen. Het zelfgemaakte programma zal hoogstwaarschijnlijk zelf een lagere footprint hebben!

[Janoz]

Wireshark is helemaal niet nodig. Het http protocol is keurig na te lezen in rfc 1945 (versie 1.0) of rfc 2616 (versie 1.1). Je hoeft maar een minimale subset te implementeren om het werkbaar te maken. Desnoods implementeer je enkel versie 1.0, dat is meer dan genoeg.