Web server

Thu Feb 15 09:36:51 UTC 2007

Hi,

Thank you Steven. shttpd seems the way to go then. Especially with the SSI and security patches.

/ Lars Törnkvist

> -----Original Message-----
> From: 
> rtems-users-bounces+lars.tornkvist=solidsoftware.net at rtems.org
>  
> [mailto:rtems-users-bounces+lars.tornkvist=solidsoftware.net at r
> tems.org] On Behalf Of Steven Johnson
> Sent: den 13 februari 2007 22:30
> Cc: rtems-users at rtems.org
> Subject: Re: Web server
> 
> Hi,
> 
> I am not a fan of the GoAhead Webserver.  We have it in our 
> product, but we are going to replace it with the shttpd one.
> 
> I wrote the port for shttpd and rtems, it is in the official 
> shttpd tree. see http://shttpd.sourceforge.net/
> 
> The BIG missing feature's by comparison to GoAhead are:
> 1. Server Side Includes (which GoAhead calls ASP, which isn't ASP).
> 2. A Security API to allow security to be set in software, 
> rather than using a security file (shttpd supports a security file).
> 
> I have just written support for Server Side Includes, it has 
> only been tested by me, and it isn't integrated into the 
> mainline yet, but the patches are in the mailing list if 
> anyone wants them.
> 
> GoAhead is larger (in code size) than shttpd. Without giving 
> a much larger set of capabilities as far as what I imagine 
> typical use in an RTEMS application would be.  It is also 
> unmaintained and contains a number of bugs (see my post that 
> Joel links to).
> 
> The API's are totally different, so it is not easy to just 
> plug in shttpd into a program that uses GoAhead.  I also 
> don't think that a simple API translation layer could be 
> written because the API's are quite different where it 
> matters.  I also however do not think it would be a huge deal 
> to cut a program using GoAhead over to shttpd.
> 
> There is also the issue that the GoAhead in RTEMS is old, 
> V2.1.4, the latest official GoAhead is V2.1.8 and there are a 
> number of known bugs to that version, my patches in my 
> previous post seek to update the version and to address as 
> many known faults as possible.  Unfortunately the licence is 
> confusing, there are several subtly different versions, but 
> it would seem to me that applying my patches to the mainline 
> and making them publicly available as a patched version of 
> GoAhead would violate at least one of the variant licences.
> 
> There is also my pet hate, the server must report itself as a 
> GoAhead server and official version (2.1.4 for RTEMS).  If 
> you apply patches to it, it is against the licence to change 
> this version number.  You also need to put the GoAhead logo 
> on your home page.
> 
> shttpd by contrast is a fully permissive licence (Beerware), 
> free for Commercial or Open Source use without restriction, 
> and there is no advertising clause, and you can make the 
> server respond with any server name/version that you like, so 
> that it can match your application.
> 
> I am still working on shttpd, and we are going to integrate 
> it into our product and totally replace GoAhead.  Part of 
> that will require I add missing feature 2 above.  I expect 
> this should be complete some time next week.
> 
> I think as a way forward, given the lack of API compatibility 
> would be to provide a copy of the shttpd tree (current as at 
> any release) and let people decide what they want to use, 
> with a note saying GoAhead is obsoleted, for the obvious 
> reasons (unsupported and restrictive licence) and that people 
> are encouraged to use shttpd (or another server of their 
> choice), and then have a road map to drop GoAhead totally in 
> a couple of
> releases.   Maybe leave GoAhead as the only web server for the next
> version (4.7), have both present in the version after the 
> next one (RTEMS 4.8?) and drop Go Ahead for (4.9).  If anyone 
> still wants to use GoAhead in 4.9 or after, there would be 
> nothing stopping them taking the code base from RTEMS and 
> sticking it in their own tree, it just wouldn't be officially 
> maintained in the RTEMS tree any more.
> 
> Steven Johnson
> 
> 
> Joel Sherrill wrote:
> > John Mills wrote:
> >   
> >> Lars, all -
> >>
> >> I have just finished integrating the GoAhead server with an eCos 
> >> application and I went back over the RTEMS mailing lists 
> when I read Lars'
> >> note. I didn't find any recent correspondence -- did 
> anyone summarize 
> >> 'Pros' and 'Cons' (as well as alternatives)?
> >>
> >>   
> >>     
> > The main issue was that the GoAhead server appears to be no longer 
> > maintained by its authors.  We have tolerated its licensing 
> > requirement for advertising since we didn't have another 
> alternative.
> >
> > Start here: 
> > http://www.rtems.org/ml/rtems-users/2006/october/msg00088.html
> >
> > Steven Johnson is across the world from us so I wouldn't expect a 
> > comment from him for a few more hours.  I hoep he can 
> update us on the 
> > status.  It seemed to be in good shape the last I knew.
> >   
> >>> >From my viewpoint, I fought through GoAhead's the 'POST' 
> upload in 
> >>> >a
> >>>     
> >>>       
> >> couple of flavors and got it working both with GoAhead's embedded 
> >> 'goforms' and conventional CGI, in Linux and eCos. I also found it 
> >> useful to export the library and to link it to a thread in our app 
> >> where I generate the web content.
> >>
> >> Finally, in response to the questions about a separate 
> build of the 
> >> compiled web content (using conventional HTML), notice that the 
> >> precompiler 'webcomp' is a native tool of your development 
> host. Even 
> >> though you it '#include's many of the source package's headers, it 
> >> can be build in the source tree and comes out as a self-contained 
> >> command-line app that generates a *.c file which becomes 
> part of your library source.
> >> Build 'webcomp' once and move it aside to use independently. See 
> >> GoAhead's Makefile for usage of 'webcomp' and on linking 
> the library. 
> >> (A suitable target already exists.)
> >>
> >>   
> >>     
> > The only technical gripes against GoAhead were that it seemed to be 
> > unmaintained and that it does not compile warning free with 
> late model 
> > gcc's.  The advertising clause in the license is just 
> another factor.
> >
> >   
> >> That said, I would be interested in a discussion (or references to 
> >> earlier
> >> discussions) of concerns and alternative web-servers for RTEMS (and
> >> similar) environments. One point I missed was the fate of the JAWS 
> >> server that I thought had once been a good choice for RTEMS use.
> >>
> >> Thanks.
> >>
> >>  - John Mills
> >>    john.m.mills at alum.mit.edu
> >>
> >> On Tue, 13 Feb 2007, Lars Törnkvist wrote:
> >>
> >>  
> >>   
> >>     
> >>> Some time ago there was a short discussion about which 
> web server to 
> >>> use with RTEMS instead of the GoAhead one. shttpd was one 
> example mentioned.
> >>> We are soon going to start working on web server 
> functionality and 
> >>> are interested in any information we can get about this.
> >>>     
> >>>       
> >>  
> >>   
> >>     
> >>> Regards
> >>> Lars Törnkvist
> >>> Solid Software AB
> >>>     
> >>>       
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.com
> >> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>   
> >>     
> >
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >
> >
> >   
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 
> 
> 