[FRPythoneers] Pros & cons of Python HTTP servers

Michael Olson Mike.Olson at fourthought.com
Mon Oct 17 13:46:37 MDT 2005


I can only speak from experience WRT 4Suite.  We added our own http  
server for a couple of reasons.  First, is x-platform.  Not so much  
from a testing POV because it turns out you still need to test pretty  
thoroughly on each platform due to difference in implementations of  
different python packages, say sockets for example.  We just wanted the  
ability to have a default web server to fall back on for each platform  
(regardless of testing scope).

The second reason we added our own HTTP server is at the time of  
initial development of 4Suite, mod-pyhton was pretty young yet and we  
had (and still have) many issues getting our py-c libraries to properly  
link with what Apache itself links with.  At various stages of 4Suite's  
life we have had it working with mod_python but changes in python  
packaging, or Apache packaging have always made it difficult for us to  
keep this working.

The third reason is that, again when mod_python was young, we wanted to  
hook into the request stream at more places then mod_python at the time  
allowed us to.  I think this is no longer an issue.

Given those initial reasons, we wrote our own HTTP server.  Then as  
mod_python progressed we just never got rid of our server and to be  
frank we never spent a lot of time getting/keeping mod_python working.   
The biggest reason for this is that we encoded a lot of our HTTP  
business logic inline when parsing the HTTP request (for performance)  
and found it very difficult to merge this logic into the Apache request  
process (with out duplicating lots of code).

I'm not 100% up to speed on current mod_python, but from what I have  
followed about the only reason now to write your own HTTP server would  
be the first reason as I think the rest of the issues are more  
manageable.

Mike

On Oct 17, 2005, at 1:29 PM, Evelyn Mitchell wrote:

> My guess has been that having a Python Web Server rather than including
> Apache, helps quite a bit with multi-OS deployment. You can't assume a
> Windows user or a Mac user has Apache installed, or would be  
> comfortable
> installing it.
>
> It certainly helps with multi-OS testing, as you really only have to  
> test
> the Python parts on one platform.
>
> Evelyn
>
> * On 2005-10-17 13:16 Jim.Vickroy at noaa.gov <Jim.Vickroy at noaa.gov>  
> wrote:
>> Sorry for the non-helpful reply, but I too have wondered about this  
>> and
>> would be interested to hear from those in "the know".
>>
>> -- jv
>>
>> ----- Original Message -----
>> From: Matt Gushee <mgushee at havenrock.com>
>> Date: Monday, October 17, 2005 9:00 am
>> Subject: [FRPythoneers] Pros & cons of Python HTTP servers
>>
>>> Hey, y'all--
>>>
>>> It's been too long since anybody's posted to this list, so ...
>>>
>>> Actually I have a somewhat serious question, though:
>>>
>>> I've noticed that every time someone develops a Web development
>>> framework/toolkit/whatever in Python, they seem to include a
>>> Python-based HTTP server. Zope did it, 4Suite did too, and now
>>> TurboGears. And I can't help wondering if that's really a good idea.
>>>
>>> I understand, of course, that having a self-contained HTTP server can
>>> make things much simpler for developers. But from the standpoints of
>>> robustness, performance, and security, it seems like a bad idea to do
>>> this in a production environment. Yet it doesn't seem that the
>>> developers of these products discourage people from using their
>>> hand-rolled servers in production, and sometimes they don't make it
>>> easyor even possible to use their products with Apache.
>>>
>>> Any thoughts on this issue, or relevant facts that people are aware
>>> of?
>>> Comments appreciated.
>>>
>>> --
>>> Matt Gushee
>>> Englewood, CO, USA
>>> _______________________________________________
>>> This message sent by the FRPythoneers mailing list.
>>> Unsubscribe: echo unsubscribe | FRPythoneers-
>>> request at lists.community.tummy.comURL:
>>> http://lists.community.tummy.com/mailman/listinfo/frpythoneers
>> _______________________________________________
>> This message sent by the FRPythoneers mailing list.
>> Unsubscribe: echo unsubscribe |  
>> FRPythoneers-request at lists.community.tummy.com
>> URL: http://lists.community.tummy.com/mailman/listinfo/frpythoneers
> This email is: [ ] actionable [x] fyi [ ] social
> Response needed: [ ] yes [x] up to you [ ] no
> Time-sensitive: [ ] immediate [x] soon [ ] none
>
>
> --  
> Regards,                    tummy.com, ltd
> Evelyn Mitchell             Linux Consulting since 1995
> efm at tummy.com               Senior System and Network Administrators
>                             http://www.tummy.com/
> _______________________________________________
> This message sent by the FRPythoneers mailing list.
> Unsubscribe: echo unsubscribe |  
> FRPythoneers-request at lists.community.tummy.com
> URL: http://lists.community.tummy.com/mailman/listinfo/frpythoneers
>
------------------------------------------------------------------------ 
-----------------
Mike Olson                                                Principal  
Consultant
mike.olson at fourthought.com                +1 720 253 4662
Fourthought, Inc.                                       
http://Fourthought.com
PO Box 270590,                                       http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management




More information about the FRPythoneers mailing list