Ian Bicking wrote: > With talk of a mini-Apache, patches to Application to get it to serven > HTTP, and all that, I thought I'd try a strategy I brought up earlier, > but which no one seemed very excited about: an HTTP-serving adapter. > I'd been working with BaseHTTPServer already (included with > Python), and > it was surprisingly easy. 1 hour later: > > http://www.colorstudy.net/software/webware/HTTPAdapter.py > > With a little testing I see no reason this couldn't be included with > Webware, providing the mini-HTTP-server that is sometimes brought up. > Maybe (maybe) not as elegant as having Application serve HTTP > directly, > but it's simple, short (160 lines), and guaranteed not to have any > adverse effect on anything else in Webware, since it touches nothing > else.
At the very least it can be included in an Experimental directory and mentioned in the docs as an easy way to get started without having a web server available. Even if there is a full-fledged HTTP Server embedded in WebKit, your method retains the option to restart the appserver without losing requests that come in during the restart. So it does have a slight advantage in that respect. > One definite bug is reading POST requests with no > Content-Length header > -- when I do self.rfile.read(), instead of > self.rfile.read(contentLength), it hangs. Probably a > subtlety of socket > programming -- no Content-Length header might simply be considered > invalid input. I would favor that approach -- reject POST requests without a Content-Length. > > While it runs in a different process from the AppServer (as > an Adapter), > for ease of running/installation it would be entirely possible to fork > off that process when the AppServer is started, giving the > illusion of a > single HTTP-serving, Python-Application-Serving program. - Geoff _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
