cherrypy http server

[Aaron Swartz]

Someone told me the other day that the [CherryPy HTTP server][1] is
threaded. A nice project for someone with some free time would be
fixing it up to support WSGI and using it to replace the
single-threaded silly WsgiServer currently in web/httpserver.py.

[1]: http://svn.cherrypy.org/branches/cribeiro-experimental/cherrypy/_cphttpserver.py

[krypton]

This doesnt affect production setup right...
it only affects when we run code like
./code.py 8080

right
thanks
krypton

> [1]:http://svn.cherrypy.org/branches/cribeiro-experimental/cherrypy/_cpht...

[Aaron Swartz]

> This doesnt affect production setup right...
> it only affects when we run code like
> ./code.py 8080

Correct.

[krypton]

Aaron did you look at how you can have

like
http://localhost:8080/shell

and it is like a python shell in cherrypy terminal

[adam.bachman]

I'll do you one better, they provide a standalone threaded WSGI server
as part of
the package:

project download: http://cherrypy.org/wiki/CherryPyDownload

direct link to the server:

http://www.cherrypy.org/browser/tags/cherrypy-3.0.1/cherrypy/wsgiserver/__init__.py?format=raw

I dropped `__init__.py` into a folder named "wsgiserver" in the web.py
package directory:

web/
__init__.py
cheetah.py
db.py
...
wsgiserver/
__init__.py

and changed `wsgi.py` like so:

-import httpserver
+import wsgiserver
...
- return httpserver.runsimple(func, validip(listget(sys.argv, 1,
'')))
+ return wsgiserver.CherryPyWSGIServer(validip(listget(sys.argv, 1,
'')), func).start()

Works like a charm, but no logging to the console. A quick change,
I'm sure.

- Adam

> [1]:http://svn.cherrypy.org/branches/cribeiro-experimental/cherrypy/_cpht...

[adam.bachman]

I'd be happy to take over cleaning it up for inclusion in the web.py
distribution if you want.

On Mar 3, 11:44 am, "adam.bachman" <adam.bach...@gmail.com> wrote:
> I'll do you one better, they provide a standalone threaded WSGI server
> as part of
> the package:
>
> project download:http://cherrypy.org/wiki/CherryPyDownload
>
> direct link to the server:
>

> http://www.cherrypy.org/browser/tags/cherrypy-3.0.1/cherrypy/wsgiserv...

[Aaron Swartz]

> I'd be happy to take over cleaning it up for inclusion in the web.py
> distribution if you want.

That'd be wonderful.

[Jack]

Has anyone been running cherrypy web server in a production
environment? Is it practical for a medium to low load site?
Say, personal site, small business site, etc. This means some
static files (images) will be served by cherrypy web server.

Also, is it secure?

--
Best regards,
Jack

[Aaron Swartz]

> Has anyone been running cherrypy web server in a production
> environment? Is it practical for a medium to low load site?
> Say, personal site, small business site, etc. This means some
> static files (images) will be served by cherrypy web server.

Someone told me over dinner that they ran a medium-load Django site on
it and it worked quite well. That's what got me interested.

> Also, is it secure?

I'm sure a lot of people would be in trouble if it wasn't...

[Craig Marshall]

> > Has anyone been running cherrypy web server in a production
> > environment?

> Someone told me over dinner that they ran a medium-load Django site on

> it and it worked quite well. That's what got me interested.

What does cherrypy provide that pure web.py doesn't? Is it just better
tested code that does the same thing, or something else? Does it
replace the web server, or complement it? (e.g. you can use web.py
with lighttpd). I suppose I should stop being lazy and do my own
research, just wondered if anyone had already done so with web.py in
mind.

Cheers,
Craig

[Aaron Swartz]

> What does cherrypy provide that pure web.py doesn't? Is it just better
> tested code that does the same thing, or something else?

Their web server is threaded, which means it can handle multiple
requests at the same time. Normally this doesn't matter, since you use
web.py with a real web server like lighttpd or Apache that handles
multiple requests at the same time. But it might be nice of web.py
could do that by itself.

[Craig Marshall]

> Their web server is threaded, which means it can handle multiple
> requests at the same time. Normally this doesn't matter, since you use
> web.py with a real web server like lighttpd or Apache that handles
> multiple requests at the same time. But it might be nice of web.py
> could do that by itself.

Thanks Aaron.

For others looking for info (I just found these):

http://en.wikipedia.org/wiki/Cherrypy
http://www.cherrypy.org/

Craig

[Istvan Albert]

On Mar 2, 1:06 pm, "Aaron Swartz" <m...@aaronsw.com> wrote:

> replace the single-threaded silly WsgiServer currently in web/httpserver.py.

That does not look like it is single threaded.

It inherits from the SocketServer.ThreadingMixIn which means that it
spawns a new thread for each request.

Now cherrypy will give you a threadpool and probably other features as
well but threading you already have.

Istvan

[Jack]

I think Istvan is right. I'd like to test multi-threading
with the WSGIServer in web.py with downloading multiple large
files and this lead to my question - how to serve static
files with the built-in web server?

--
Best regards,
Jack

[adam.bachman]

I've got a version of the WSGI server working with web.py. I also
whipped up two pieces of middleware; one to handle requests for /
static/ files and one to log requests to the console (like the old
httpserver.py).

I've left the server in its own directory, along with the two
middleware scripts (static.py and logger.py) to keep the main web.py
directory from becoming too cluttered. Leaving the original wsgi
server file (wsgiserver/__init__.py) relatively untouched means
patches will be simple if improvements are made in the CherryPy trunk.

The two pieces of middleware are relatively untested, I'd check
carefully for platform issues (because we're screwing with paths) and
large file issues before releasing it to production. I've tested it
on Windows XP with files up to 48 MB and it works, but it isn't meant
to be a heavy duty file server. I'd be curious to see profiling stats
if anyone is serious about making it work for real world use.

The license for the server is BSD and included with the server.
Aaron, what's the procedure for committing new code to the project?

- Adam

[adam.bachman]

I've posted a .zip file containing the code for wsgiserver and a patch
for wsgi.py if anybody wants to try it out.

http://adambachman.org/projects/wsgiserver.zip

- Adam

[Aaron Swartz]

> Aaron, what's the procedure for committing new code to the project?

Generally, you post a patch file and dedicate your work to the public
domain and Anand tests it and commits it.

[adam.bachman]

Sounds good, I've updated http://adambachman.org/projects/wsgiserver.zip
to clean up the middleware components and add licensing info.
CherryPy is BSD licensed, I don't think that conflicts too much, but
I'm not well educated in the intricacies of license blending.
The zip file contains the patch for web/wsgi.py and the wsgiserver/
package.

Anand, feel free to contact me with questions, make any changes
necessary to get it production ready.

[Istvan Albert]

two comments,

1. the most common exploit of static content is returning a file that
is not in the web root (via relative paths). I have not tested the
code you have, just looked but did not notice any protection against
it.

2. returning whole files is not a good idea, CP has (used to have) a
streaming output option where it returns the content of the file as an
iterator

Istvan

[Anand]

On 07-Mar-07, at 8:55 PM, adam.bachman wrote:

>
> Sounds good, I've updated http://adambachman.org/projects/
> wsgiserver.zip
> to clean up the middleware components and add licensing info.
> CherryPy is BSD licensed, I don't think that conflicts too much, but
> I'm not well educated in the intricacies of license blending.
> The zip file contains the patch for web/wsgi.py and the wsgiserver/
> package.
>
> Anand, feel free to contact me with questions, make any changes
> necessary to get it production ready.

Thanks Adam.

I have done some modifications and checked in to the trunk.
Now web.py trunk uses CherryPy WSGI server by default.
Please test this out and let me know if there are any problems.

Incase if you are facing any problems with the new server, you can
fallback to the old server by adding the following line before
web.run in your application.

web.httpserver.runsimple = web.httpserver.runbasic

[Jack]

Hello Anand,

Does this address the two comments made by Istvan Albert
<istvan...@gmail.com>?

------------ cut ------------
two comments,

------------ cut ------------

--
Best regards,
Jack

[Anand]

>
> 1. the most common exploit of static content is returning a file that
> is not in the web root (via relative paths). I have not tested the
> code you have, just looked but did not notice any protection against
> it.

SimpleHTTPRequestHandler takes care of that and that functionality is
reused.

> 2. returning whole files is not a good idea, CP has (used to have) a
> streaming output option where it returns the content of the file as an
> iterator

Yes. it send in chunks of 16KB.

[Jack]

Excellent! Thanks for the clarification.

[krypton]

Hey Adam
Thanks for the awesome work
How do we use the cherrypy server in production
Thanks
Krypton

[Anand]

> How do we use the cherrypy server in production

Try latest code from trunk.