Re: [Tclhttpd-users] Advice on embedding Tclhttpd

[Jan K. <jj...@gm...>]

Am Montag, 6. November 2006 10:42 schrieb Trevor Davel:
>
> I am also concerned by the apparent lack of development -- this could
> indicate a lack of use & support, or product maturity ;)
>
I am using tclhttpd as an "configuration webserver" in a commercial product.

So far, I had no big problems with it. Most annoying for me was tclhttpd comes 
as a script to be sourced, not as a proper tcl package. So it can be a little 
tricky to put it into another tcl application.

On the other hand, the code is more or less easy to understand and patches are 
easy to develop, as soon you had diven into it.


Lack of development -- I would say, tclhttpd is kind of abadoned. I myself had 
put a (not proper, though) patch on this list, which allows "Content 
encoding: gzip;". Not a single reply... 

If Jeffrey or Brent aren't interested in tclhttpd any more, I presume someone 
(we) should adopt this project. I have great interest in tclhttpd as it is 
neccessary for my application.


> Can anyone comment on Tclhttpd's reliability and security, preferably with
> reference to case studies in a hostile production environment?
>
> What about the pace of development?  For example, bug [1446208] (server is
> open
> for xss attacks) was opened in March 2006 -- I would have thought XSS bugs
> would
> deserve high priority?  Is there a roadmap for 3.5.x / 3.6, given that
> 3.5.1 is
> over two years old?
>
Well, Cross-Site-Scripting vulnerability is heavily dependent on the content 
generated. The web server itself doesn't do much processing of the input 
data, so I'm pretty sure it could be cured very easily if there happens to be 
a hole (in the web server, not just in the example pages).


> Embedding Tclhttpd
>
> The application we are developing is not simply a web app -- it is a
> service with various interfaces that performs periodic processing.  In
> short we want to use Tclhttpd to provide an interface, not to provide the
> structure of the application.  In addition, the web interface will be
> entirely dynamic -- we have
> no need to serve files.
>
Ah! Same here.


> And this is where my real problems start ;)
>
> With some effort I have reworked the httpd.tcl and httpdthread.tcl startup
> files
> to remove all file system access, and pared down the required library files
> until I found a minimal set that (sort-of) works.  I have done this in an
> attempt to ensure that certain functionality is strictly unavailable.
>
> I am still facing a bunch of bugs because the internals of Tclhttpd assume
> the
> availability of various commands, and some of those commands are not
> obvious (i.e. they are only called from error paths).  For example,
> Doc_Error is called by Url_Unwind (which handles exceptions in the
> dispatcher), but doesn't
> work properly without the httpd::doc package, which provides filesystem
> access
> and pulls in most of the functionality of Tclhttpd ;(
>
Is it absolutely neccessary in your application to have *no* file system 
access? For my application, I just tuned the document root to an empty 
directory and worked with "Direct_Url" only.


>
> What I think I am aiming for is to have a reusable, embeddable httpd
> package.
> Something like this:
>   % package require embedhttpd
>   1.0
>   % embedhttpd::init -host 127.0.0.1 -port 81 -webmaster
> <mailto:xx...@yy...> xx...@yy...
>
>   % embedhttpd::error_handler my_error_proc
>   my_error_proc
>   % embedhttpd::url_handler / my_root_proc
>   / my_root_proc
>   % embedhttpd::start
>   Server listening on 127.0.0.1:81
>
> So my question is: has anyone done something like this before, and do you
> have
> some advice for me? ;)
>
My goal, too. Unfortunately, I found no time working on that so far. Your code 
below reads good...

Kind regards

	Jan
-- 
Alles Schwere kommt von oben...