[Web-SIG] New django-hotsauce development group
Hi, I'm pleased to announce the availability of a new public discussion group for Django-hotsauce: https://groups.google.com/forum/#!forum/django-hotsauce Talented CPython and PyPy developers are invited to join and meet the django-hotsauce community. Best regards, Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Django-hotsauce 0.7.8 release
Hi everyone, I'm very happy to announce the release of Django-hotsauce 0.7.8, a scalable and non-monolithic web microframework on top of Django and others! What's new: - This release fixes a major issue when WSGIMiddleware is being mounted on top of WSGIController. - Implemented thread-local storage for HTTP requests on top of Werkzeug/Gevent. - Fixed libschevo for supporting Gevent based asynchronous operations in ZODB. Release notes: http://www.isotopesoftware.ca/wiki/DjangoHotSauce/Releases/Release-0.7.8 Download: http://www.isotopesoftware.ca/pub/django-hotsauce/django-hotsauce-0.7.8.tar.gz I recommend everyone to update to 0.7.8. It is by far the most stable release of Django-hotsauce! :) Cheers, Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?
I fixed this bug! :)
My application logic was causing a redirect loop in the oauth2
authentication mecanism.
Have a nice day,
E
Le 2017-08-10 à 06:25, Etienne Robillard a écrit :
Hi,
A little update on this issue. I switched to werkzeug/gevent for
storing the http request in a thread-local object. I also use a
contextmanager to set the current request for a thread. However, since
the value of REMOTE_USER is set from a WSGI middleware, it doesn't
persist into my thread-local request object.
Here's my code:
@contextmanager
def sessionmanager(environ):
_requests.request = RequestClass(environ)
yield
_requests.request = None
def get_current_request():
try:
return _requests.request
except AttributeError:
raise TypeError("No request object for this thread")
request = LocalProxy(lambda: get_current_request())
[...]
def application(self, environ, start_response):
self._session.environ.update(environ)
with sessionmanager(self._session.environ):
response = self.get_response(request=request)
try:
return response(self._session.environ, start_response)
finally:
_requests.request = None
#self._session.environ.clear()
Any suggestions how to improve this code to allow the value of
REMOTE_USER to persist if and only if the user has been authenticated ?
Thank you in advance,
Etienne
Le 2016-10-12 à 05:42, Etienne Robillard a écrit :
I believe the OAuth2 middleware and client is functioning correctly
and is setting the REMOTE_USER value as expected. But I guess the
problem is because I recreate a new WebOb request object before
returning a WSGI response. Also, I need to update the WSGI
environment for each request in order to preserve the value of
REMOTE_USER. However, i don't know if it's logical to recreate a WSGI
request every time. Perhaps the solution would be to use a global
request object...
--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?
Hi,
A little update on this issue. I switched to werkzeug/gevent for storing
the http request in a thread-local object. I also use a contextmanager
to set the current request for a thread. However, since the value of
REMOTE_USER is set from a WSGI middleware, it doesn't persist into my
thread-local request object.
Here's my code:
@contextmanager
def sessionmanager(environ):
_requests.request = RequestClass(environ)
yield
_requests.request = None
def get_current_request():
try:
return _requests.request
except AttributeError:
raise TypeError("No request object for this thread")
request = LocalProxy(lambda: get_current_request())
[...]
def application(self, environ, start_response):
self._session.environ.update(environ)
with sessionmanager(self._session.environ):
response = self.get_response(request=request)
try:
return response(self._session.environ, start_response)
finally:
_requests.request = None
#self._session.environ.clear()
Any suggestions how to improve this code to allow the value of
REMOTE_USER to persist if and only if the user has been authenticated ?
Thank you in advance,
Etienne
Le 2016-10-12 à 05:42, Etienne Robillard a écrit :
I believe the OAuth2 middleware and client is functioning correctly
and is setting the REMOTE_USER value as expected. But I guess the
problem is because I recreate a new WebOb request object before
returning a WSGI response. Also, I need to update the WSGI environment
for each request in order to preserve the value of REMOTE_USER.
However, i don't know if it's logical to recreate a WSGI request every
time. Perhaps the solution would be to use a global request object...
--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?
Hi Randy, Thanks for your comment. Le 2016-10-11 à 19:44, Randy Syring a écrit : For what it's worth, I also think you might misunderstand how WSGI works. I believe the environment object is supposed to exist in a request context. I'm assuming you only need one user per request, so simply filling in the value of REMOTE_USER seems to me like it should work. However, I haven't looked at your code or thought long about the problem, it's just an off-handed observation based on your description below. I believe the OAuth2 middleware and client is functioning correctly and is setting the REMOTE_USER value as expected. But I guess the problem is because I recreate a new WebOb request object before returning a WSGI response. Also, I need to update the WSGI environment for each request in order to preserve the value of REMOTE_USER. However, i don't know if it's logical to recreate a WSGI request every time. Perhaps the solution would be to use a global request object... Regards, Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?
Here's the source code: https://bitbucket.org/tkadm30/django-hotsauce/src/6a862e22e045cb10a84f3b08e4c237ed592ecec7/lib/notmm/controllers/wsgi.pyx A live demo is here: http://www.isotopesoftware.ca/ The problem is in the init_request method. The current implementation uses threading.local. I have no idea how to make the WSGI environ object a thread-local in case the remote user has been logged in. Any input would be greatly appreciated. Regards, Etienne Le 2016-10-10 à 10:30, Etienne Robillard a écrit : Hi, I'm attempting to develop a OAuth 2.0 authentication middleware which sets REMOTE_USER variable into the WSGI environ object, however I'm unable to make this variable unique for the logged user. Is it recommended to use threading.local or gevent to make the WSGI environment persisting on a per-request basis ? What others options can you advise to make private request data not accessible in WSGI ? Thanks in advance, Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?
Hi, I'm attempting to develop a OAuth 2.0 authentication middleware which sets REMOTE_USER variable into the WSGI environ object, however I'm unable to make this variable unique for the logged user. Is it recommended to use threading.local or gevent to make the WSGI environment persisting on a per-request basis ? What others options can you advise to make private request data not accessible in WSGI ? Thanks in advance, Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] no_authkit_users_in_environ
Hello,
I'm trying to make cookie auth working with authkit but cannot
find a healthy solution. So far here's the code which i'm trying
to use for getting a users object into the environ:
#!/usr/bin/env python
from notmm.controllers.wsgi import WSGIController
from notmm.controllers.auth import LoginController
from notmm.utils.http import httpserver
from notmm.utils.configparse import loadconf
sample_app = WSGIController()
settings = sample_app.settings
global_conf = loadconf('auth.conf')
auth_conf = global_conf['authkit']
auth_app = LoginController(sample_app, auth_conf, settings=settings)
if __name__ == '__main__':
httpserver.daemonize(auth_app, ('localhost', 8000))
And here's the login view to handle authentication:
def authenticate_user(request, username, password, tokens='',
user_data=time.ctime,
authfunc='paste.auth_tkt.set_user'):
Authenticate the user into the site and update the last_modified
timestamp if authentication and authorization granted user access.
try:
user_setter_func = request.environ[authfunc]
if valid_password(request.environ, username, password):
user_setter_func(username, tokens=tokens, user_data=user_data())
#trigger function here to update the last_modified timestamp
log.debug('User %s has been authenticated and authorized access!!'
% username)
raise NotAuthenticatedError
except (KeyError, Exception):
raise NotAuthenticatedError
return None
controller:
class AuthCookieController(SessionController):
Authentication controller to delegate authorization to generic
user-defined backends.
request_class = HTTPRequest
response_class = HTTPResponse
def __init__(self, wsgi_app, auth_conf=None, **kwargs):
super(AuthCookieController, self).__init__(**kwargs)
#put a pointer on the previous wsgi app in the stack
self.wsgi_app = wsgi_app
self.auth_conf_wrapper = auth_middleware(wsgi_app,
app_conf=auth_conf,
cookie_secret='secret string',
#handle_httpexception=False,
valid=self.authenticate,
#enforce=self.auth_conf['enforce']
)
def application(self, environ, start_response, exc_info=None):
# apply the response middleware wrapper to
# the WSGI stack and return a callable obj
return self.auth_conf_wrapper(environ, start_response)
def authenticate(self, username, password):
Authenticate with the provided ``username`` and ``password``.
Developers are expected to override this method in custom
authentication subclasses.
if username == password:
return username
else:
return None
LoginController = AuthCookieController
the traceback:
/home/steiner/src/notmm/trunk/examples/auth/views/login.py(33)authenticate_user()
- if valid_password(request.environ, username, password):
(Pdb) bt
/home/steiner/src/notmm/trunk/examples/auth/redirect.py(15)module()
- httpserver.daemonize(auth_app, ('localhost', 8000))
/home/steiner/src/notmm/trunk/lib/notmm/utils/http/httpserver.py(157)daemonize()
- server.serve()
/home/steiner/src/notmm/trunk/lib/notmm/utils/http/httpserver.py(115)serve()
- self.server.serve_forever()
/usr/local/lib/python2.7/SocketServer.py(238)serve_forever()
- self._handle_request_noblock()
/usr/local/lib/python2.7/SocketServer.py(295)_handle_request_noblock()
- self.process_request(request, client_address)
/usr/local/lib/python2.7/SocketServer.py(321)process_request()
- self.finish_request(request, client_address)
/usr/local/lib/python2.7/SocketServer.py(334)finish_request()
- self.RequestHandlerClass(request, client_address, self)
/usr/local/lib/python2.7/SocketServer.py(649)__init__()
- self.handle()
/usr/local/lib/python2.7/wsgiref/simple_server.py(124)handle()
- handler.run(self.server.get_app())
/usr/local/lib/python2.7/wsgiref/handlers.py(85)run()
- self.result = application(self.environ, self.start_response)
/home/steiner/src/notmm/trunk/extras/libauthkit/authkit/authenticate/base.py(314)__call__()
- return self.app(environ, start_response)
/home/steiner/src/notmm/trunk/extras/libauthkit/authkit/authenticate/cookie.py(480)__call__()
- return self.app(environ, cookie_setting_start_response)
/home/steiner/src/notmm/trunk/extras/libauthkit/authkit/authenticate/multi.py(87)__call__()
- app_iter = app(environ, start_response)
/home/steiner/src/notmm/trunk/extras/libauthkit/authkit/authenticate/multi.py(55)app()
- return self.default(environ, find)
/home/steiner/src/notmm/trunk/extras/libauthkit/authkit/authenticate/base.py(304)__call__()
- return self.app(environ, start_response)
/home/steiner/src/notmm/trunk/examples/auth/views/login.py(96)login()
- authenticate_user(request, username, password)
Re: [Web-SIG] [RFC] Introducing the Emerging-Like Web Applications Protocol 1.0
Hi Ian, Thanks for spotting this to my attention. I've sent a reply also but it too went blocked, so what have appeared on web-sig is mostly incomplete. Here's the relevant links again for your convenience: http://gthc.org/blog/agile-development/introducing-emerging-like-web-applications-protocol/ http://gthc.org/WebApplicationDevelopment/EmergingLikeWebApplications Kind regards, Etienne Ian Bicking wrote: FYI, your post went through to web-sig but without the links...? On Wed, Oct 21, 2009 at 7:09 AM, Etienne Robillard robillard.etie...@gmail.com wrote: Hi, Here's a link to a blog entry I've posted about the Emerging-Like Web Applications Protocol 1.0. I've completed written the initial revision and wanted to pass it along to the pros. Since the development of WSGI specifications seems a little slowed, I hope this may helps developers to think in new ways to see development of web frameworks in Python and WSGI. ;-) Also, this made me think that refactoring WSGI in much smaller parts or modules could be helpful and less of a burden than a single document with multiple versioning... What do you think, can creating a modular specification for WSGI helps in nailing down new directions for Python web development ? Kind regards, Etienne http://gthc.org/blog/agile-development/introducing-emerging-like-web-applications-protocol/ P.S - I tried to send it over to web-...@python.org. But my e-mail address is being blocked as spam. Why is that so ? Why are we putting blockers on legitimate recipients ? I thought web-...@python was an open list, but apparently only a relatively short list of persons seems to have the priviledge of free speech on that forum. This is somewhat a frustrating, and IMO is a long standing problem with this Python community. This report relates to a message you sent with the following header fields: Message-id: 4adeeb31.9000...@gmail.com Date: Wed, 21 Oct 2009 07:06:25 -0400 From: Etienne Robillard robillard.etie...@gmail.com To: notmm-disc...@googlegroups.com Subject: Introducing the Emerging-Like Web Applications Protocol 1.0 Your message cannot be delivered to the following recipients: Recipient address: web-sig@python.org Reason: Rejection greeting returned by server. Diagnostic code: smtp;220-mail.python.org ESMTP Postfix 5.7.1 Blocked by DNSBL Remote system: dns;mail.python.org (TCP|10.23.32.55|50078|82.94.164.166|25) (mail.python.org ESMTP Postfix) -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: 178A BF04 23F0 2BF5 535D 4A57 FD53 FD31 98DC 4E57 ___ 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] Getting back to WSGI grass roots.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René Dudfield wrote: On Wed, Sep 23, 2009 at 1:03 PM, Aaron Watters arw1...@yahoo.com wrote: --- On Wed, 9/23/09, Graham Dumpleton graham.dumple...@gmail.com wrote: So, rather than throw away completely the idea of bytes everywhere, and rewrite the WSGI specification, we could instead say that the existing conceptual idea of WSGI 1.0 is still valid, and just build on top of it a translation interface to present that as unicode. Seconded. There should be a lower level that talks bytes and a higher level that talks unicode or whatever. There should also be a way for even higher levels to reach down to the lower level to see the bytes before they got misdecoded by the unicode layer because this will likely be needed in some cases. Is there anything wrong with just adding decoded interpretations to the WSGI environment as separate entries? Also, everything should be as orthogonal as possible. One problem I have with most Web tools and frameworks is they tend to take over and do everything at once when I really only want a little bit of help. WSGI 1 is nice because it just abstracts HTTP and stops there. It was a beautiful piece of work. Kudos. Yeah, wsgi is definitely useful for a wide range of uses cases. Except it's currently not working for a number of use cases... but we can't accommodate them. eg, unicode, tainting, http proxies, http clients, user supplied buffers, async, latest http RFCs, different uses of http compared to 2003, all features of http. This is clear by the variety of web frameworks that don't use wsgi, and the variety of things layered on top of wsgi. There's room for other specifications which consider those use cases not covered by wsgi. http proxies cover the main wsgi use case of being able to use applications on many servers(apache, nginx lighttpd etc) . Things like webob, and cherrypy allow python frameworks to coordinate at a higher level avoiding wsgi as well. It's also clear that async frameworks can be used with wsgi in a non blocking manner given things like the greenlets/stackless and the Eventlet library - which makes use of two underlying async frameworks(twisted, and libevent) given that all of your blocking calls to libraries can be swapped out with versions written for async... like many have already(eg you can use a urllib api like library). We have to keep remembering what the purpose of wsgi is. Opening line of wsgi spec: This document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers. By limiting its scope we do get something useful out of it(for some people). Application portability is the main wsgi use case. I think that requires a number of things that wsgi doesn't provide - wsgi knows nothing of data stores for example. Application portability is the main thing we should be interested in, and strive for it. Not just on web servers, but on web frameworks too. There's no way I can take any python web application, copy the files onto any python web server and have it work. php can do this, but we still can not do this with python. Well, I kinda disagree. You can easily distribute eggs or whatever Python packages to your favorite HTTP web server and have them working in your current WSGI stack. At least, I don't seem to get how PHP makes this more easily than with Python. Perhaps putting some lights here would be helpful. Please let web frameworks be web frameworks and peps be peps! That is, allow some flexibility for web frameworks designs by writting clear and concise peps, but also forget about fairy features that would increase the document size over 1MB... ;-) Regards, Etienne ___ 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/robillard.etienne%40gmail.com - -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: 178A BF04 23F0 2BF5 535D 4A57 FD53 FD31 98DC 4E57 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq6IZQACgkQ/VP9MZjcTldOcQCgyEsupfDxrSIpwVBK85iCuOCZ cwQAnRWov+VTQqT2T/4gw84hqnjkL7dG =moxq -END PGP SIGNATURE- ___ 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] PEP 0333 and PEP XXXX Updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Armin Ronacher wrote: Hi, Graham Dumpleton schrieb: Regardless of the details of changes being made to the PEP and the creation of any new ones, do we need to first agree on the overall direction we are going to take. Ie., the grand plan at a high level. Indeed. The 0333 changes are mostly uncontroversial and can be discovered separately. So far the discussions on this mailinglist in the last days only covered what would be a new WSGI version which is in the file. What I am getting at here is that the likes of PJE has indicated a preference for skipping any WSGI 1.1 altogether and going straight to WSGI 2.0. If there isn't going to be support all round for even coming out with WSGI 1.1, then don't want to see time wasted trying to come up with a new PEP only for what is needed to change. The time wasted on is not that much, it's just your #3 written down to text with the unicode return values. So, I am starting to get nervous that we could go to a great deal of work to try and resolve the various issues for a specific definition, only to find that people don't even agree that such a version is warranted and we get a deadlock. WSGI 1.1 as currently specified in would be pretty uncontroversial on Python 2.x because of the str/unicode coercion that Python implicitly applies and that this is basically the only change. 1. Clarifications and corrections to existing WSGI for Python 2.X Is already in 0333 in the repository. 2. Come up with a version of WSGI for Python 3.X. The whole bytes versus unicode discussion. That is in , just that this new version of WSGI also works in Python 2.x and is unicode based. 3. Drop the start_response() function and ability to use its write() function returned as result. What people have been calling WSGI 2.0. That would be too many changes at the same time. We can specify WSGI 2.0 at the same time based on and just change the return value to ``(app_iter, status, headers)`` and drop the `start_response`. But that really breaks applications and workflows and I don't think everybody would swtich over to that right away. The first question is, should Python 2.X forever be bytes everywhere, or if we start introducing unicode [...] Latest version of specifies ist as unicode for 2.x and 3.x except where native strings still make sense. In my definitions I introduced 'native' string along with 'bytes' and 'unicode' string in an attempt to try and be able to use one set of language which would describe WSGI and be interpretable in the context of both Python 2.X and Python 3.X. is basically that. The second question is, do we want to try and come up with something for Python 3.X, ie., (2) above, while still preserving the current start_response() callback, or do we instead want to jump direct to WSGI (Python 3.X) 2.0, ie., combine (2) and (3) above, and say that there is no WSGI 1.X for Python 3.X at all? does not drop start_response. That would break too much code (all middlewares and it's not straightforward to write middlewares for both start_response and without then). For example, one option for a roadmap would keep bytes everywhere in Python 2.X and jump direct to WSGI 2.0 in Python 3.X. IMO WSGI 1.0 should just fix the small problem it has, and WSGI 1.1 goes to unicode in both versions. WSGI (Python 2.X) 1.1 - Clarify existing WSGI by adding (1) above. WSGI (Python 2.X) 2.0 - Drop start_response() from WSGI (Python 2.X) 1.1. Keep bytes everywhere. WSGI (Python 3.X) 2.0 - Adapt WSGI (Python 2.X) 2.0 to Python 3.X. Use definition #4 (or more likely a variation on it). For that I would rather go like this: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a modified version of PEP WSGI 3.0 like XXX but drops start_response Good plan but I'm afraid now only a bunch of elite people on this list is going to remember all the details on theses upcoming specifications. Why the rush to specify WSGI 3.0 and not focus mainly on the next one ahead ? With regards, Etienne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq2JIYACgkQ/VP9MZjcTlePlwCfQKKjLp0ZUyObFJvYbUHIARdY sqwAoJ99JgdKaIVjw5SZfXveFS+tSj7/ =VHY9 -END PGP SIGNATURE- ___ 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] WSGI 2
basis what encoding is used, but this is entirely optional. Note that there is no requirement to deal with RFC 2047. Ugh. This is where I'm not happy with how WSGI 1 in Python 3 has been treated. I think it should be bytes, just like it is in Python 2. I still don't understand what is the practical, vs theoretical use case for that in Python 3. In Python 2 bytes strings work out okay because url routing rules through whatever means is generally also going to be defined in terms of byte strings. In Python 3 however, routing is going to likely default to being defined with strings and as such, any information like SCRIPT_NAME, PATH_INFO and QUERY_STRING are going to have to almost immediately be converted to strings from bytes to apply routing rules anyway. Can you expand on what benefits come from and what practical use case would predominate that would mean that bytes would be the better option? But if we have an encoding, I guess UTF8 is okay so long as it uses PEP 383: http://www.python.org/dev/peps/pep-0383/ -- for the most part PEP 383, and putting the encoding that was used into the environment, makes transcoding doable. PEP 383 doesn't allow for transcoding unless you keep track of the encoding used, so we have to store that in the environment. Again, what practical use cases are there where transcoding would be necessary, especially if it was a requirement that the WSGI adapter/server at lowest level, if it makes sense for that server infrastructure, ie., can support something other than UTF-8, to provide an option to supply WSGI environ values, all or selected, interpreted as a different encoding? If the option is at the WSGI adapter/server level and managed at the point of original translation from bytes, then a WSGI application or middleware doesn't need to worry about it. As such, noting what encoding was used in the environment serves no purpose except for information purposes. Marking what encoding was used also would not necessarily be straight forward if the WSGI adapter/server provided a way of overriding encoding used for specific values, because one value for encoding indicator would not suffice. To allow experimentation with encoding of values, current mod_wsgi code allowed overriding of values on global or individual basis. This was done via an Apache directive, but as had to pass this information from main Apache worker process to mod_wsgi daemon process, did it in such a way that also visible to application for information purposes at this point. Was using convention as follows. # Override encoding for everything to UTF-8. mod_wsgi.variable_encoding: UTF-8 # Override encoding and pass raw byes for everything. mod_wsgi.variable_encoding: - # Override encoding of specific value to UTF-8. mod_wsgi.variable_encoding.SCRIPT_NAME: UTF-8 # Override encoding and pass raw bytes for specific value. mod_wsgi.variable_encoding.SCRIPT_NAME: - If default encoding used for everything, then no value passed at all. In respect of passing bytes for values, we get back to argument from past discussions as to what should be passed as bytes. Do you only do SCRIPT_NAME, PATH_INFO and QUERY_STRING? What about server specific variables such as REQUEST_URI? What about headers such as Referrer? What about custom user values set using something like SetEnv directive in Apache? This is where it started to turn into a can of worms last time. You either treat everything as UTF-8 to be consistent, or use bytes for everything, in which case a great deal more work is put onto WSGI applications even for potentially simple stuff, effectively forcing the use of high level request wrappers like WebOb or request object in Werkzeug. In summary, what are the practical uses cases that would make passing bytes over UTF-8 or even latin-1 worthwhile? If passing bytes, what values should be passed as bytes and what left alone? What practical use cases are there that would necessitate transcoding? It's probably harder for newbies to understand transcoding, and converting bytes to string, and vice-versa. I think that count as a practical use case so that high-level frameworks can do some wrapping around, thus potentially making the WSGI spec significantly harder to implement in derivatives works. Thus, I'd not recommend to make WSGI 2 more obfuscated than necessary, unless supported by real-case scenarios as Graham suggested. Hoping not to have leaked too much fuel on the fire.. ;) Etienne -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC ___ 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] Announcing bobo
Martin, I don't care about '97, pretty much. I think that if this Jim guy has lots of experience then at least he could not pretend that other people works are made by/for geniuses, which is probably untrue anyway. There's other ways to advertise a open source project. One method is to discriminate other projects, thus making it's own work appears better in some ways or another. Of courses this has nothing to do in being a genius.. You don't have to be a genius to copy-and-paste things. regards, Etienne Martijn Faassen wrote: Hey, On Tue, Jun 16, 2009 at 4:51 PM, Etienne Robillardrobillard.etie...@gmail.com wrote: Nothing very new here. At least next time try to be a little more creative, otherwise this is getting slightly boring and repetitive... It's a bit rich to call Jim Fulton uncreative concerning web development. I suggest you delve into the history of Python web development for a bit. Of course back in '97 there was more to invent than there is today. Regards, Martijn -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC ___ 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] Announcing bobo
Hey, don't you people know that you could use a more polite word than Hey to salute people ? I'm just telling my own views. If you disagree then please say something more meaningful than this. Who cares what you know. Senthil Kumaran wrote: On Tue, Jun 16, 2009 at 12:15:29PM -0400, Etienne Robillard wrote: I think that if this Jim guy has lots of experience then at least he could not pretend that other people works are made by/for geniuses, which is probably untrue anyway. Hey, I don't understand why are being so negative with your comments. Does not sound good. I surely dont know what your contributions are, but I do know what Jim Fulton's contributions are. -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC ___ 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] Announcing bobo
I recommend you quit using latin to try looking smarter. ;) I do I'm discouraged to see so much adversion between Python web frameworks fighting for the same goal. To say that you don't to be a genius implies that all other web frameworks are made for geniuses, which is probably offending for less-mature projects. Of courses I might have misread or taking for granted that this was a totally new project.. My apologies then to Jim... ;) Regards, Etienne This feels like an ad hominem argument which is both surprising and unproductive. Nathan regards, Etienne Martijn Faassen wrote: Hey, On Tue, Jun 16, 2009 at 4:51 PM, Etienne Robillardrobillard.etie...@gmail.com wrote: Nothing very new here. At least next time try to be a little more creative, otherwise this is getting slightly boring and repetitive... It's a bit rich to call Jim Fulton uncreative concerning web development. I suggest you delve into the history of Python web development for a bit. Of course back in '97 there was more to invent than there is today. Regards, Martijn -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC ___ 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/nathan%40yergler.net -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC ___ 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] Announcing bobo
Pfft, I bet this thread would have never happened without my initial intervention. Likewise, I think you're just using this thread for your own interests, disregarding my own arguments on why web frameworks are so hard to cope with. If you want to start a thread for Bobo, please switch mailing-list or create a new thread, as all I wanted was to tell Jim my disappointement regarding Bobo, and I still think its not very revolutionary. Regards, Etienne C. Titus Brown wrote: Hey all, I think we can pretty safely ignore Etienne as either a troll or an unnecessarily rude person. Has anyone looked at Bobo yet? I'd be interested in comparisons between it and Quixote, which is what I've mostly used in the past. I believe that Bobo begat Zope, which begat Quixote as (I thought) an attempt to return to Bobo-style programming, and so I'm curious about what sort of choices Bobo has made. thanks, --titus -- Etienne Robillard robillard.etie...@gmail.com Green Tea Hackers Club http://gthc.org/ Blog: http://gthc.org/blog/ PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC ___ 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] Could WSGI handle Asynchronous response?
On Mon, 18 Feb 2008 04:23:38 -0800 (PST)
est [EMAIL PROTECTED] wrote:
I am writing a small 'comet'-like app using flup, something like
this:
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Flup works!\n']-Could this be part
of response output? Could I time.sleep() for a while then write other
outputs?
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(myapp, multiplexed=True, bindAddress=('0.0.0.0',
)).run()
So is WSGI really synchronous? How can I handle asynchronous outputs
with flup/WSGI ?
maybe start by looking here:
http://twistedmatrix.com/trac/browser/trunk/twisted/web2/wsgi.py
Regards,
Etienne
___
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] Using decorators to add objects in a thread-local store..
On Jul 15, 4:44 pm, Mike Orr [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 1:42 PM, Etienne Robillard [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008 16:09:18 -0400 Etienne Robillard [EMAIL PROTECTED] wrote: Hi all, I'd like to have your input and comments on using decorators functions for adding extra options to the request.environ object. For instance, here's a decorator whichs adds a scoped session object into request.environ: def with_session(engine=None): Decorator function for attaching a `Session` instance as a keyword argument in `request.environ`. def decorator(view_func): def _wrapper(request, *args, **kwargs): scoped_session.set_session(engine) request.environ['_scoped_session'] = getattr(scoped_session, 'sessio return view_func(request, *args, **kwargs) return wraps(view_func)(_wrapper) return decorator Then it can be used as follows: @with_session(engine=engine): def view_blog_list(request, *args, **kwargs): # get the local session object for this # request (thread-local) sess = request.environ['_scoped_session'] # do stuff with the Session object here... ... Is this a good approach, or can this be adapted to work in multithreaded environments ? For details, you can checkout the source code of notmm, which holds the current implementation of the with_session decorator: $ hg clone -r tiphttp://gthc.org/projects/notmm/repo/notmm For more details about notmm, please see here:http://gthc.org/projects/notmm/ Thanks and Regards, Etienne Hi, I'm forwarding this on pylons-discuss. I'd be interested in feedback on how to integrate SQLAlchemy in Pylons. Can this decorator (with_session) works on/with Pylons controllers too ? This is the standard way.http://wiki.pylonshq.com/display/pylonsdocs/Using+SQLAlchemy+with+Pylons Ah yes. I forgot that document, it explains really closely what I was trying to do with the with_session decorator... Some notable differences: - myapp/model/meta.py: I just throw that stuff in a file named myapp/ config/environment.py. - myapp/model/__init__.py : Likewise, I defined a get_model() which is essentially a clone of init_model. It just returns a `Table` instance for a given table_name. It puts a scoped session object at myapp.model.meta.Session Interesting. To put this in constrast with the with_session object, the only difference I see is the place to store and retrieve the Session object. (request.environ vs meta..) I suppose the decorator would work, but it's not typical for an action to read things directly from the environment unless it's something Pylons doesn't support any other way. Well, I like refering to a web project by its name, rather than refering to it as a framework X project. For that reason I think 'typical' doesn't apply here, since supporting Pylons might not be it. I just read Pylons code for inspiration and technical guidance... :) -- Mike Orr [EMAIL PROTECTED] Thanks! Etienne ___ 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] Using decorators to add objects in a thread-local store..
On Tue, 15 Jul 2008 21:32:39 -0500 Ian Bicking [EMAIL PROTECTED] wrote: Etienne Robillard wrote: Hi all, I'd like to have your input and comments on using decorators functions for adding extra options to the request.environ object. For instance, here's a decorator whichs adds a scoped session object into request.environ: def with_session(engine=None): Decorator function for attaching a `Session` instance as a keyword argument in `request.environ`. def decorator(view_func): def _wrapper(request, *args, **kwargs): scoped_session.set_session(engine) request.environ['_scoped_session'] = getattr(scoped_session, 'sessio You should always use a namespace, e.g., request.environ['something._scoped_session'] = ... In the context of a Pylons controller you could do it this way. Of course with just WSGI it would be better to wrap it via WSGI, which is almost equivalent to a decorator: def with_session(engine=None): def decorator(app): def engine_wsgi_app(environ, start_response): environ['...'] = ... return app(environ, start_response) return engine_wsgi_app return decorator Tried, but its giving me headaches.. I think I will stick with the former... Plus, in webob, it is my assumption that Request objects returns a wsgi application with get_response(). This indicates most likely that both approaches are the same. :) Pylons controllers aren't *quite* WSGI applications, but instances of those controller classes are. So wrapping an individual controller with middleware requires a bit more work. Ah. I just have a conflicting view regarding the definition of a 'middleware'. For me, middlewares shouldn't even exists, as I'm not even sure where they should fit in the WSGI pipeline.. In fact, I consider middlewares as a potential security hole... @with_session(engine=engine): def view_blog_list(request, *args, **kwargs): # get the local session object for this # request (thread-local) sess = request.environ['_scoped_session'] # do stuff with the Session object here... ... Is this a good approach, or can this be adapted to work in multithreaded environments ? Since you are passing around arguments to functions it should be fine in threaded environments. Thanks. I'd definitely like to see more discussion regarding threads in the next version of WSGI. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org Kind Regards, Etienne ___ 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
[Web-SIG] Using decorators to add objects in a thread-local store..
Hi all, I'd like to have your input and comments on using decorators functions for adding extra options to the request.environ object. For instance, here's a decorator whichs adds a scoped session object into request.environ: def with_session(engine=None): Decorator function for attaching a `Session` instance as a keyword argument in `request.environ`. def decorator(view_func): def _wrapper(request, *args, **kwargs): scoped_session.set_session(engine) request.environ['_scoped_session'] = getattr(scoped_session, 'sessio return view_func(request, *args, **kwargs) return wraps(view_func)(_wrapper) return decorator Then it can be used as follows: @with_session(engine=engine): def view_blog_list(request, *args, **kwargs): # get the local session object for this # request (thread-local) sess = request.environ['_scoped_session'] # do stuff with the Session object here... ... Is this a good approach, or can this be adapted to work in multithreaded environments ? For details, you can checkout the source code of notmm, which holds the current implementation of the with_session decorator: $ hg clone -r tip http://gthc.org/projects/notmm/repo/ notmm For more details about notmm, please see here: http://gthc.org/projects/notmm/ Thanks and Regards, Etienne ___ 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
