[Tclhttpd-users] Advice on embedding Tclhttpd

[Trevor D. <Tr...@pr...>]

Hi everyone,
 
I have recently started to look at Tclhttpd as a means to provide a web 
interface to an application.  My team has used Tcl to develop products
before
and we have a function library we'd like to use in a new application, but 
a web interface may be more appropriate than the Tk interfaces we have
previously developed.
 
Tclhttpd looks like it can do the job, but I have some concerns and I'd like

to know if anyone can give me some advice.
 
Reliability & Security
 
There are a couple of comments and testimonials around concerning the
stability
and reliability of Tclhttpd, and they seem to be positive.  On the other
hand
I have seen little comment on the security of Tclhttpd.  
 
I am also concerned by the apparent lack of development -- this could
indicate
a lack of use & support, or product maturity ;)
 
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?
 
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.
 
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 ;(
 
I have looked at minihttpd and it doesn't seem to be an appropriate solution
--
I'm looking for a solution that is a little more functional (and tested).
I am also aware of http://wiki.tcl.tk/10198 <http://wiki.tcl.tk/10198>
(minimal tclhttpd) but it seems to
be a couple of years out of date ;(
 
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? ;)
 

Thanks,
Trevor (Twylite)
 

# Minimal embeddable Tclhttpd
 
# Only the following lib files are required:
# cookie.tcl
# direct.tcl
# httpd.tcl
# log.tcl
# logstd.tcl
# pkgIndex.tcl
# url.tcl
# utils.tcl
# version.tcl
 
package require md5   ;# required by httpd::utils but not used in this httpd
package require ncgi  ;# needed to parse http requests
package require httpd ;# main server
package require httpd::version ;# version information
package require httpd::log     ;# server has Log calls in various places
package require httpd::utils   ;# one or two functions used in other places
package require httpd::url     ;# URL dispatcher, part of main server
package require httpd::cookie  ;# easy access to cookies, required by direct
package require httpd::direct  ;# direct URL domain support
 

# Required for non-threaded implementation
proc Thread_Respond {args} {return 0}
proc Thread_Enabled {} {return 0}
 
set use_httpd_counter 0
if { $use_httpd_counter } {
  package require httpd::counter
} else {
  # I don't really care about counting & statistics, but httpd expects
  # these functions to be available
  proc Counter_Init {args} { }
  proc Count {what {delta 1}} { }
  proc CountName {instance tag} { }
  proc CountHist {what {delta 1}} { }
  proc CountStart {what instance} { }
  proc CountStop {what instance} { }
}
 
# httpd::direct uses Cgi_SetEnv to provide an environment to direct URL
# procs -- I don't really care about that
proc Cgi_SetEnv {sock path {var env}} { }
 

# If you don't have doc_error.tcl you'll need to define Doc_NotFound and 
# Doc_Error
 
proc Doc_NotFound { sock } {
  Httpd_ReturnData $sock text/html "Not found"
 Httpd_Error $sock 404 
}
 
proc Doc_Error { sock ei } {
  Httpd_ReturnData $sock text/html "Internal error"
 Httpd_Error $sock 500 
}
 

# Set up the dynmaic domain handler for the root URL
 
Direct_Url / rooturl
proc rooturl {} { return <html><body>Alpha</body></html> }
 
# The URL dispatcher has a problem with / is the only domain and it is set
# up using direct.  Workaround is to create an additional direct URL prefix.
 
Direct_Url /dummy rooturl
 
# Initialise the server
 
Httpd_Init
Counter_Init 60
Httpd_Webmaster xx...@yy... <mailto:xx...@yy...> 
Httpd_Server 81 localhost 127.0.0.1
 

NOTICE :  this electronic mail and any attachments ("message") contains
privileged information intended only for the addressee(s) use.  If you are
not the/an intended recipient, you may not disclose, review, disseminate,
retransmit, copy, use or take action in reliance upon or otherwise deal with
or publish this message, which is subject to copyright ("Use").  You may not
use this message for anything other than the purpose for which it is
intended.  If you have received this message in error, you are required to
notify the writer and delete it. Prism Holdings Limited, its holding
companies and its subsidiaries ("Prism") accept no liability whatsoever as a
result of any losses arising from persons placing reliance on any
information contained in this message or and Use thereof.  The views
expressed in this message are those of the individual transmitting it,
unless they are expressly stated to be those of Prism.  It is the
recipient's obligation to scan this message and ensure that it contains no
viruses or other malicious programs and the recipient is warned that,
notwithstanding reasonable checks performed by Prism, viruses and harmful
programs may be contained in this message and Prism accepts no liability
whatsoever for any loss, damage, or liability of any nature, whether direct
or indirect, resulting from the recipient accessing or Using this message or
any files attached to it.