Re: [Web-SIG] wsgiref questions
On Fri, 2006-22-12 at 13:26 -0800, Guido van Rossum wrote: One of the downsides of Python's efficiency is that it's often easier to code than to reuse! I was thinking this very same thing earlier this week. This can sometimes be unfortunate. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
On 12/22/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: We decided to add chunking encoding to our own server, it wasn't all that hard. Hopefully you will release this code as part of wsgiref and let the community benefit from it, right? We didn't modift wsgiref, we added it to a proprietary module; and I don't think our code has anything to offer over what's already available through other channels, such as the CherryPy server. (Also, wsgiref violates a couple of Python style guides that make me not want to update it myself. Phillip promised he would clean it up for distribution but never did, so the version distributed with Python 2.5 has a few strange ideosyncracies that I'm afraid to clean up because last time someone touched Phillip's code he threw a fit.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
On 12/22/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: We decided to add chunking encoding to our own server, it wasn't all that hard. Hopefully you will release this code as part of wsgiref and let the community benefit from it, right? We didn't modift wsgiref, we added it to a proprietary module; Makes sense that you can't release it then :) and I don't think our code has anything to offer over what's already available through other channels, such as the CherryPy server. True but the thing is that it's wsgiref which belongs to the stdlib not CherryPy, it'd be nice if the reference WSGI server could be a little more complete I suppose. Besides for some obscure reason some people have a bad opinion of CP. (Also, wsgiref violates a couple of Python style guides that make me not want to update it myself. Phillip promised he would clean it up for distribution but never did, so the version distributed with Python 2.5 has a few strange ideosyncracies that I'm afraid to clean up because last time someone touched Phillip's code he threw a fit.) Oh good then that I didn't try to understand the Content-Length bug I raised a few months ago on HEAD requests :) Thanks for the feedback by the way. Much appreciated. - Sylvain ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
On 12/22/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: We decided to add chunking encoding to our own server, it wasn't all that hard. Hopefully you will release this code as part of wsgiref and let the community benefit from it, right? We didn't modift wsgiref, we added it to a proprietary module; and I don't think our code has anything to offer over what's already available through other channels, such as the CherryPy server. (Also, wsgiref violates a couple of Python style guides that make me not want to update it myself. Phillip promised he would clean it up for distribution but never did, so the version distributed with Python 2.5 has a few strange ideosyncracies that I'm afraid to clean up because last time someone touched Phillip's code he threw a fit.) One question popped into my mind. One of the core idea behind WSGI is the pluggability of components respecting the interface proposed by PEP 333. I wonder if there was reason not to try a different WSGI server when facing a limitation with wsgiref rather than using a proprietary module? CherryPy server or another does not matter. Of course since I have no clue of your infrastructure and design I'm not judging here but your feedback would be interesting on that particular case. I'm intrigued :) Thanks, - Sylvain ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
At 09:55 AM 12/22/2006 -0800, Guido van Rossum wrote: (Also, wsgiref violates a couple of Python style guides that make me not want to update it myself. Phillip promised he would clean it up for distribution but never did, I only have the vaguest recollection of you mentioning this, but can't find any actual emails about it. As far as I know, I incorporated fixes for all of your bug reports, either using your patches or my own. Would you mind refreshing my memory as to the style issues or ideosyncracies you are referring to? so the version distributed with Python 2.5 has a few strange ideosyncracies that I'm afraid to clean up because last time someone touched Phillip's code he threw a fit.) If by fit you mean the one email I sent to Python-dev requesting that others hold off on changes to wsgiref, please note that it was based on: 1. my misunderstanding the policy for changes to externally-distributed modules (like wsgiref) and the nature of the purpose of having a designated maintainer for contributed stdlib modules, 2. at a time when I was working on incorporating documentation and code patches and suggestions from the Web-SIG in order to finish the Python 2.5 version of wsgiref and release a matching external version for older Pythons, all with a tight deadline. AND, I had just spent a few hours work that had to be redone when I discovered that changes (other than the automated whitespace normalization) had been taking place on the trunk. Since I now understand the policy clearly, and am not attempting to integrate anything into either version of wsgiref, you are quite safe from any emails from me regarding your changes, with the possible exception of questions regarding changed functionality. And even that isn't likely to happen for a while, since I don't foresee making any new external releases of wsgiref any time in the next few months, barring an emergency due to some horrible bug being discovered. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
Guido, Getting another piece of open source code added to Google's infrastructure (and learning how to use it) would have been an order of magnitude more effort than writing the ~50 lines of code that we ended up adding. That's striking. Out of curiosity, can I ask what exactly the bureaucracy looks like for open source code to be used at Google? Since we're talking WSGI the learning curve is pretty much nil, so the bureaucracy must be heavy. Is it mostly a licensing issue? Or is it quality assurance? chad ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
On 12/22/06, Chad Whitacre [EMAIL PROTECTED] wrote: Getting another piece of open source code added to Google's infrastructure (and learning how to use it) would have been an order of magnitude more effort than writing the ~50 lines of code that we ended up adding. That's striking. Out of curiosity, can I ask what exactly the bureaucracy looks like for open source code to be used at Google? Since we're talking WSGI the learning curve is pretty much nil, so the bureaucracy must be heavy. Is it mostly a licensing issue? Or is it quality assurance? I think I'm done discussing Google internals. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
I think I'm done discussing Google internals. D'oh! ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
On 12/20/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:06 PM 12/20/2006 -0800, Guido van Rossum wrote: On 12/20/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:12 AM 12/20/2006 -0800, Guido van Rossum wrote: We're struggling to use wsgiref behind some Googlish infrastructure, and one of the issues we find is that there is code that forbids hop-by-hop headers. Unfortunately we have a reason to send one (Transfer-encoding). Are you sure it's not a Content-Encoding? No, chunked is definitely a transfer encoding. What's the reason behind their prohibition, and what would be the right way to do this? See the thread here for the original rationale: http://mail.python.org/pipermail/web-sig/2004-September/000879.html Well, we're using wsgiref's simple_server which only speaks HTTP/1.0, but we really need to speak HTTP/1.1 and use chunked. Where do you recommend we put the chunking instead? It's expected that an HTTP/1.1 server would handle chunking in the case where a WSGI app yields individual blocks, assuming that the client supports chunking and the server chooses to do it that way. The way the spec is written, the server *must* ensure that each yielded chunk is transmitted to the client before the application is asked for the next chunk. However, it's the server's choice as to whether the chunks will just be streamed or transmitted using chunked encoding. wsgiref does have this comment at one point in the code (wsgiref.handlers), btw: # XXX Try for chunked encoding if origin server and client is 1.1 This is the place where you could try to add support for doing this. I.e., that's the place where you'd add the Transfer-Encoding header, after checking for client support. Yeah, but we'd like not to edit wsgiref, so our code won't depend on a hacked version of it... By the way, if your goal is just to ensure that data is written to the client as its yielded by the application, that can be done without needing the chunked encoding. My understanding is that all chunked encoding is good for is sending data of unknown length over a persistent connection. simple_server doesn't support persistent connections (and WSGI doesn't have connections), so chunking is of use only if you have some crazy kind of client that needs the chunking for some reason known only to its developers. :) And guess what, that's exactly the situation we're in. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
Sylvain Hellegouarch wrote:
Well, we're using wsgiref's simple_server which only speaks HTTP/1.0,
but we really need to speak HTTP/1.1 and use chunked. Where do you
recommend we put the chunking instead?
shameless-plug
If you are not to fuss about which WSGI server you can afford to use,
you could grab the server from CherryPy 3.0 which is HTTP/1.1 fluent.
from cherrypy import wsgiref [1]
You'd be done.
/shameless-plug
Because an example is worth all the words:
from cherrypy import wsgiserver
def my_crazy_app(environ, start_response):
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['Hello world!\n']
# This won't call CherryPy machinery at all
# Only the WSGI server which is independant from CherryPy itself
# Its name simply reflects its origin...
server = wsgiserver.CherryPyWSGIServer(('localhost', 8070), [('/',
my_crazy_app)], numthreads=10, server_name='localhost')
# Want SSl support? Just set those attributes
# server.ssl_certificate = ...
# server.ssl_private_key = ...
if __name__ == '__main__':
server.start()
The nice thing is that you can also support many WSGI applications in
one instance of your server. Anyway only for those who'd be interested ;)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
Guido, Well, we're using wsgiref's simple_server which only speaks HTTP/1.0, but we really need to speak HTTP/1.1 and use chunked. Where do you recommend we put the chunking instead? shameless-plug If you are not to fuss about which WSGI server you can afford to use, you could grab the server from CherryPy 3.0 which is HTTP/1.1 fluent. I'll give a +1 to CherryPy's wsgiserver.py module. It's well-written, robust, and lightly coupled. If you're at all interested in a light-weight pure-Python WSGI server (rather than a library), you might check out Aspen: http://www.zetadev.com/software/aspen/ CherryPy's module is at the core of Aspen. If you just want a module, definitely check out CherryPy's. chad ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref questions
At 08:51 PM 12/20/2006 +, Sylvain Hellegouarch wrote: [1] http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver.py Guido, it does appear that this server implements chunked encoding if you: 1. Use a status of 200, 203, or 206 2. Don't include a Content-Length header 3. *Yield* each chunk from your application as a separate block (i.e. don't use write()) Sylvain, it appears that the above code has a bug in its chunked support if an application uses write() calls. It will set the encoding to chunked, but it won't actually write the data in chunks when write() is called. You might want to pass that information back to the CherryPy developers, although I think there are probably some reading this list. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
