Il 24/03/2013 06:14, PJ Eby ha scritto:
> [...]
>> Thanks for response PJ,
>> that is what I, unfortunately, didn't want to hear, the validator being
>> correct for the "spec" means I can't use it for my asynchronous stuff, which
>> is a shame :-(((
>> But why commit to send headers when you may no
Il 23/09/2010 18:32, P.J. Eby ha scritto:
> Just a reminder: I'm planning to actually update PEP 333 over the
> weekend and start working on wsgiref updates, so if you have any
> last-minute comments on the proposal, now's the time to post them,
> however unpolished they may be!
>
Where can I find
Ludvig Ericson ha scritto:
I have put web-sig in Cc.
> On 11 apr 2010, at 22:07, Manlio Perillo wrote:
>
>> I here propose the x-wsgiorg.suspend to be accepted as official WSGI
>> extension, using the wsgiorg namespace.
>
> I'm sorry, but I don't see how such
And Clover ha scritto:
> [...]
>> 8. The value passed to the 'write()' callback returned by
>>'start_response()' should be a byte string. Where native strings
>>are unicode strings, a native string type can also be supplied, in
>>which case it would be encoded as ISO-8859-1.
>
> Weren'
Dirkjan Ochtman ha scritto:
> Mostly taking Graham's list of issues and incorporating it into PEP 333.
>
> Latest revision: http://hg.xavamedia.nl/peps/file/tip/wsgi-1.1.txt
>
> Let's have comments here (comments in the form of diffs are
> particularly welcome, of course). Remember, the idea is n
Dirkjan Ochtman ha scritto:
> [...]
> --- pep-0333.txt 2010-04-15 14:46:02.0 +0200
> +++ wsgi-1.1.txt 2010-04-15 14:51:39.0 +0200
> @@ -1,114 +1,124 @@
> [...]
> Abstract
>
>
> [...]
> -Thus, simplicity of implementation on *both* the server and framework
> -
Dirkjan Ochtman ha scritto:
> [...]
>> Such a significant change as removing the requirement for write()
>> should also not be done within a minor version of the WSGI
>> specification because anything that works with WSGI 1.0 should still
>> work with WSGI 1.1 and vice versa. On that basis it can't
Dirkjan Ochtman ha scritto:
> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
> wrote:
>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>
>> And when I say 'last attempt', yes there have been people who have
>> stepped up to try and get this to happen in the past. I thin
Dirkjan Ochtman ha scritto:
> On Tue, Apr 13, 2010 at 13:13, Graham Dumpleton
> wrote:
>> There is no such thing as a WSGI 2.0 PEP and there is no proper
>> concensus either on what it should look like. Thus if you see anything
>> claiming to implement WSGI 2.0, then it isn't and you should only v
P.J. Eby ha scritto:
> At 10:18 PM 4/8/2010 +0200, Manlio Perillo wrote:
>> Suppose I have an HTML template file, and I want to use a sub request.
>>
>> ...
>> ${subrequest('/header/'}
>> ...
>>
>> The problem with this code is that, sinc
Graham Dumpleton ha scritto:
> [...]
>> Just yielding an empty string does not give the server some important
>> informations.
>>
>> As an example, with x-wsgi.suspend application can specify a timeout,
>> that tells the server that the application must be resumed before
>> timeout milliseconds hav
P.J. Eby ha scritto:
> At 01:25 PM 4/12/2010 +0200, Manlio Perillo wrote:
>> The purpose of the extension if to just have a standard interface that
>> WSGI applications can use to take advantage of the possibility, offered
>> by asynchronous server, to suspend executio
Graham Dumpleton ha scritto:
> [...]
>>
>> Claiming that x-wsgiorg.suspend does not help writing portable WSGI
>> application is something similar (well, I'm a bit exaggerating here) of
>> saying that WSGI does not allow to write portable web applications,
>> because real world WSGI applications ne
Graham Dumpleton ha scritto:
> On 12 April 2010 06:07, Manlio Perillo wrote:
>> I'm not sure about the correct procedure to follow, I hope it is not a
>> problem.
>>
>> I here propose the x-wsgiorg.suspend to be accepted as official WSGI
>> extension, using t
P.J. Eby ha scritto:
> At 02:04 PM 4/10/2010 +0100, Chris Dent wrote:
>> I realize I'm able to build up a complete string or yield via a
>> generator, or a whole bunch of various ways to accomplish things
>> (which is part of why I like WSGI: that content is just an iterator,
>> that's a good thing
Gustavo Narea ha scritto:
> Hello,
>
> Maybe I'm missing something obvious, but if the gateway doesn't support
> applications that return write() callables, then it's not WSGI.
>
> A callable that raises an exception does not even count. It's obvious
> that they must not raise exceptions -- Then
he lack of start_response support,
the usability is limited.
Thanks and regards Manlio Perillo
___
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/arch
will starte a new thread for official approval process.
I have tried to write as much documentation possible, also taking into
consideration feedback received in previous threads; thanks for the support.
Thanks and regards Manlio Perillo
___
Web-SIG ma
Graham Dumpleton ha scritto:
> On 9 April 2010 22:15, Manlio Perillo wrote:
>> Graham Dumpleton ha scritto:
>>> [...]
>>>> But since the write callable **can** be implemented in a middleware
>>>> (using greenlets) and since middlewares *can* be configured
Graham Dumpleton ha scritto:
> [...]
>> But since the write callable **can** be implemented in a middleware
>> (using greenlets) and since middlewares *can* be configured inside WSGI
>> gateway, implementations can still claim to be WSGI 1.0 conformant.
>
> Then only the higher level middleware ad
Graham Dumpleton ha scritto:
> [...]
>>- the name will be 'wsgiorg.suspend' instead of 'wsgi.pause_output'
>>
>> The wsgiorg namespace is used, since the plan is to have it
>> standardized [1], but it can only be implemented on asynchronous
>> servers.
>
> Please read:
>
> ht
I have started to write an asynchronous WSGI implementation for Twisted Web.
The standard implementation execute the WSGI application in a separate
thread.
twsgi will instead execute the application in the main Twisted thread.
The advantage is that twsgi is better integrated in Twisted, and WSGI
P.J. Eby ha scritto:
> At 08:06 PM 4/8/2010 +0200, Manlio Perillo wrote:
>> What I'm trying to do is:
>>
>> * as in the example I posted, turn Mako render function in a generator.
>>
>> The reason is that I would lite to to implement support for Nginx
>&g
P.J. Eby ha scritto:
> At 05:40 PM 4/8/2010 +0200, Manlio Perillo wrote:
>> With WSGI 2.0 we will end up with:
>>
>> - WSGI 1.0, a full featured protocol, but with hard to implement
>> middlewares
>> - WSGI 2.0, a simple protocol, with more easy to implement mid
P.J. Eby ha scritto:
> At 04:59 PM 4/8/2010 +0200, Manlio Perillo wrote:
> [...]
>> There should be a sample WSGI 2.0 implementation for CGI, and a sample
>> WSGI 1.0 -> 2.0 adapter.
>>
>> This adapter should be able to support the coroutine example,
>> >
Aaron Watters ha scritto:
> someone remind me: where is the canonical WSGI 2 spec?
http://wsgi.org/wsgi/WSGI_2.0
> I assume there is a way to "wrap" WSGI 1 applications
> without breaking them? Or is this the regex-->re fiasco
> all over again?
>
start_response can be implemented by a function
Hi.
Some time ago I objected the decision to remove start_response function
from next version WSGI, using as rationale the fact that without
start_callable, asynchronous extension are impossible to support.
Now I have found that removing start_response will also make impossible
to support corouti
Manlio Perillo ha scritto:
> Hi.
>
> In this period I'm upgrading my WSGI implementation for Nginx:
> http://hg.mperillo.ath.cx/nginx/ngx_http_wsgi_module/
> [...]
> So, I was thinking: what about a WSGI middleware that, using greenlets,
> expose to the application
Hi.
In this period I'm upgrading my WSGI implementation for Nginx:
http://hg.mperillo.ath.cx/nginx/ngx_http_wsgi_module/
I'm not only updating the code to work with recent Nginx versions (after
2 years) but, above all, I'm cleaning up the code, removing stuff not
strictly required and hard to ma
Dirkjan Ochtman ha scritto:
> On Tue, Mar 30, 2010 at 11:28, Manlio Perillo
> wrote:
>> Note however, that Mercurial has fixed the problem:
>
> So, as the guy who inherited Mercurial's hgweb WSGI application (or
> rather, made it much more WSGI-compliant),
Did you
Graham Dumpleton ha scritto:
> [...]
>> Here is the culprit:
>> http://lists.alioth.debian.org/pipermail/python-modules-team/2009-January/003514.html
>> http://code.google.com/p/modwsgi/issues/detail?id=82
>>
>> So it seems safe, when the Log object used in wsgi.errors is also used
>> to replace s
Manlio Perillo ha scritto:
> Hi.
>
> Some time ago, someone reported me that an application embedded in Nginx
> with my WSGI module failed to execute, since in my implementation the
> wsgi.errors object does not implement the .close method.
>
> [...]
> Any idea?
>
Graham Dumpleton ha scritto:
> On 28 March 2010 22:21, Manlio Perillo wrote:
>> Graham Dumpleton ha scritto:
>>> [...]
>>>> Unfortunately I never got to know what application or framework was
>>>> causing the problem.
>>>>
>>>>
Graham Dumpleton ha scritto:
> [...]
>> Unfortunately I never got to know what application or framework was
>> causing the problem.
>>
>> Any idea?
>
Sorry, my question was not clear.
I was asking what applications or frameworks call the .close method on
the errors object.
I want to check if:
*
Hi.
Some time ago, someone reported me that an application embedded in Nginx
with my WSGI module failed to execute, since in my implementation the
wsgi.errors object does not implement the .close method.
The same object type is used to replace sys.stderr.
Of course, both trying to close wsgi.err
Alex Morega ha scritto:
> On 17 Mar 2010, at 13:47, Manlio Perillo wrote:
> [...]
>>> =
>>> [daemon]
>>> factory = egg:PasteScript#wsgiutils
>>> host = 127.0.0.1
>>> port = 8000
>>> app = my_site
>>>
>&
Alex Morega ha scritto:
> On 17 Mar 2010, at 0:24, Manlio Perillo wrote:
>
>> Alex Morega ha scritto:
>>> Hello,
>>>
>>> This is not really a WSGI question, it's more into general configuration,
>>> but I don't know of a better place to
Alex Morega ha scritto:
> Hello,
>
> This is not really a WSGI question, it's more into general configuration, but
> I don't know of a better place to ask it.
>
> Paster config files allow you to hook up WSGI applications, middleware, and a
> server, plus some (undocumented?) magic configuratio
Gustavo Narea ha scritto:
> Hello,
>
> We're considering migrating from mod_wsgi to FastCGI (Apache) because
> we'll need to use versions of Python compiled by ourselves.
>
Note that you can simply recompile mod_wsgi to use your custom Python.
> [...]
Manlio
__
Hi.
Recently I have implemented these two functions:
http://paste.pocoo.org/show/170198/
I would like to know if it is worth to have them as a saparate functions
or if there is a better method to get the host name and the request URI
path.
About the host_name function, what is the reason why i
Graham Dumpleton ha scritto:
Note: I'm sending the entire message to the mailing list.
> 2009/12/7 Manlio Perillo :
>> Hi.
>>
>> I'm playing with Python 3.x, current revision.
>>
>> I have noted that the data in the os.environ are noe Unicode strings.
&
Hi.
I'm playing with Python 3.x, current revision.
I have noted that the data in the os.environ are noe Unicode strings.
In a CGI application, HTTP headers are Unicode strings, and are decoded
using system default encoding.
In a future WSGI application, HTTP headers are Unicode strings, and are
Henry Precheur ha scritto:
> On Fri, Dec 04, 2009 at 07:40:55PM +0100, Manlio Perillo wrote:
>> What are the functions that does not works with byte strings?
>
> Just to make things clear, I was talking about Python 3.
>
I know.
Unfortunately I don't have installed Pyt
Henry Precheur ha scritto:
> On Fri, Dec 04, 2009 at 10:17:09AM +0100, Manlio Perillo wrote:
>> It is just as simple as using byte strings, IMHO.
>
> No, it's not. There were lots of dicussions regarding this on the
> mailing list. One of the main issue is that the stan
And Clover ha scritto:
> Manlio Perillo wrote:
>
>> Words of *TEXT MAY contain characters from character sets other than
>> ISO-8859-1 [22] only when encoded according to the rules of RFC 2047
>
> Yeah, this is, unfortunately, a lie. The rules of RFC 2047 apply only to
Henry Precheur ha scritto:
> On Thu, Dec 03, 2009 at 09:15:06PM +0100, Manlio Perillo wrote:
>> There is something that I don't understand.
>>
>> Some HTTP headers, like Accept-Language, contains data described as
>> `token`, where:
>>
>> token
And Clover ha scritto:
> Manlio Perillo wrote:
>
>> However what about URI (that is, for PATH_INFO and the like)?
>> For URI (if I remember correctly) the suggested encoding is UTF-8, so
>> URLS should be decoded using
>
>> url.decode('utf-8', 's
Henry Precheur ha scritto:
> [...]
>> How is authorization username handled in common WSGI frameworks?
>
> As far as I know, they don't handle this. They just return the string
> without dealing with the encoding issues.
>
> I think there is no correct way of handling this, because 99% of
> usern
And Clover ha scritto:
> [...]
>> Cookie data SHOULD be transparent to the server/gateway; however WSGI is
>> going to assume that data is encoded in latin-1.
>
> Yeah. This is no big deal because non-ASCII characters in cookies are
> already broken everywhere(*). Given this and other limitations
Manlio Perillo ha scritto:
> Hi.
>
> I'm doing some tests to try to understand how HTTP headers are encoded
> by browsers.
>
> I have written a simple WSGI application that asks authentication
> credentials and then print them on the terminal and return the data a
Hi.
I'm doing some tests to try to understand how HTTP headers are encoded
by browsers.
I have written a simple WSGI application that asks authentication
credentials and then print them on the terminal and return the data as
response, as raw bytes
http://paste.pocoo.org/show/154633/
Then I used
e_bytes = cookie.encode('latin-1', 'surrogateescape')
and then decode it using UTF-8:
my_cookie_data = cookie_bytes.decode('utf-8')
This is a bit unreasonable, but I don't know if this is a common
practice (I do this, just to make an example).
Manlio Perillo
___
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
you the
backend process id an unique key.
You can use this data to send a cancellation request.
All you need to do is to pass the process id and the unique key to the
client (with some encryption so that the client can use the data only once).
Unfortunately, libpq does not offer a flexible interface
very early stage.
> [...]
Regards Manlio Perillo
___
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
Isn't more appropriate for wsgiref.util.setup_testing_defaults function
to set SERVER_PROTOCOL to HTTP/1.1, instead of HTTP/1.0, since HTTP/1.1
is the current version of the protocol?
Thanks Manlio Perillo
___
Web-SIG mailing list
We
Hi.
I have noted that some WSGI based web applications use the standard
logging module, for logging.
However I have some doubts about how this works when the application is
embedded in a web server that uses multiple processes (like Nginx or
Apache with prefork).
Thanks Manlio Perillo
Thomas Broyer ha scritto:
On Sun, Dec 14, 2008 at 11:23 AM, Manlio Perillo wrote:
In my WSGI applications I always have an ending slash to the URLs.
This means that an URL without the ending slash will cause the underlying
resource to return 404 Not Found HTTP response.
What is the best method
interesting.
Regards Manlio Perillo
___
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
dd an option to my URL dispatcher to force any URL to
have an ending slash (as an example requesting an HTTP redirect - either
302 or 301, or by just internally modifying the URL), but I'm not sure
this is the best solution.
Thanks Manlio Perillo
_
lux.com/draft-coar-cgi-v11-03.txt"; is broken.
[...]
Regards Manlio Perillo
___
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
ng to return 304 Not
Modified)
Regards Manlio Perillo
___
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
Phillip J. Eby ha scritto:
At 08:49 PM 11/17/2008 +0100, Manlio Perillo wrote:
Ian Bicking ha scritto:
[...]
We need to propose a change to the WSGI specification. I propose, in
"Input and Error Streams"
(http://www.python.org/dev/peps/pep-0333/#input-and-error-streams) we
ch
WSGI 2.0
You can't just modify the current WSGI 1.0 spec.
I'm for 2), with the other clarifications about WSGI we have discussed
in the past.
Regards Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.pytho
with very little coding effort at the python
level.
Personally I think that implementing a standard reactor in Python is bad.
The Micro-Threading should just offer an API, like Twisted Deferred,
generators and greenlets do; the reactor should be imple
.net.ru/nginx/upload.en.html
that does this (but don't transcode in application/www-form-urlencoded.
Any one interested?
I really whould like some reviews.
Thanks Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.pytho
nd not a byte string.
In other cases, I would say returning a byte string is the
correct thing to do.
I'm not sure to understand.
If you want non text data in the POST request body, you can use the file
control.
I can't really see use cases of normal input fields having byte
content of form post to be
encoded "text" string?
Or it should be considered encoded "byte" string?
> [...]
Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
blindly guess the encoding.
I first try the content-type header, then the special _charset_ field,
and finally utf-8.
If there is a problem in the decoding, the client is broken (or there is
a bug in the application).
So the correct response is Bad Request, I
used in the encoding.
I think that it is safe to decode data from the QUERY_STRING and POST
data to Unicode, and to return Bad Request in case of errors.
If the user have specialized needs, he can use low level parsing functions.
In wsgix the "high" level functions are parse_query_st
o strings, but using "replace" error handling.
Can you point me to the discussion on python-dev list?
Bill
Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.pyth
Ian Bicking ha scritto:
Manlio Perillo wrote:
Hi.
In my WSGI framework:
http://hg.mperillo.ath.cx/wsgix
I have, in the `http` module, the functions `parse_query_string` and
`parse_simple_post_data`.
The first parse the query string and return a dictionary of strings, the
latter parse the
in the mailing
list archive).
But this support has not been standardized.
How can I handle asynchronous outputs
with flup/WSGI ?
Regards Manlio Perillo
___
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
ks do.
Django seems to convert to Unicode, but the Python standard library does
not (and I would like to know if changes are planned for Python 3.x).
Thanks Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org
Assuming that WSGI requires the uri to not be encoded, then the solution
is to do modify the request_uri function replacing:
quote(SCRIPT_NAME) with:
quote(unquote(SCRIPT_NAME))
?
Where can I find informations about alternate encoding scheme?
Thanks Manlio Perillo
VPN it performs very bad.
wsgiref is an iterative server, if I not wrong; it serves only one
request at a time.
On the loopback interface this is not a problem, but on Internet the
latency of the connection make a single request time high.
pa
Donovan Preston ha scritto:
On Jul 8, 2008, at 11:45 AM, Manlio Perillo wrote:
Using greenlets, there is always a current greenlet, so you can use
this for local storage.
A library function can check if there is an active greenlet, and use
it as data key; otherwise it will use the current
hat does
not make use of greenlets.
> [...]
Manlio Perillo
___
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
Phillip J. Eby ha scritto:
At 11:21 PM 7/7/2008 +0200, Manlio Perillo wrote:
So this is not a "bad" middleware, IMHO.
True, but it's part of the application, rather than being transparent.
Ok, I agree.
Does this means that such non trasparent middlewares must not be
inse
y not just store
the values inside the WSGI environ dictionary?
It is a per request dictionary, so it is really what you want.
> [...]
Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Uns
Phillip J. Eby ha scritto:
At 09:58 PM 7/7/2008 +0200, Manlio Perillo wrote:
In this case the first solution is to use this middleware as a
decorator, instead of a full middleware.
This is the correct way to implement non-transparent middleware; i.e.,
so-called middleware which is in fact an
the cookie (this is possible but harder to
implement and less flexibile to use).
Any suggestions?
Thanks Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mai
Ian Bicking ha scritto:
Manlio Perillo wrote:
[...]
As an example, in Paste you have choosed to using config dictionary
for middleware configuration, that is, you have middleware factories.
I think this is a red herring. WebOb specifically doesn't do anything
related to configurati
Ian Bicking ha scritto:
Manlio Perillo wrote:
I'm adding web-sig in Cc.
[...]
I'm developing a WSGI framework with all these (and other) ideas:
http://hg.mperillo.ath.cx/wsgix
Its still not documented, so I have not yet made an official
announcement.
The main design goal is t
ike additional interfaces (like Request and Response) objects
around the WSGI dictionary, and I don't like frameworks like Django that
completely hides the WSGI interface.
> [...]
Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
We
Iwan Vosloo ha scritto:
On Fri, 2008-07-04 at 13:42 +0200, Manlio Perillo wrote:
Iwan Vosloo ha scritto:
Hi,
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt with.
Passing it all via parameters to every nook
but I have not checked how the twisted people deal with the issue.)
The natural solution with WSGI is to store objects in the environ
dictionary.
In fact in my web applications I always pass the environ dictionary
explicitly to every functions.
> [...]
Manlio
Christopher Stawarz ha scritto:
On May 21, 2008, at 1:34 PM, Manlio Perillo wrote:
Instead, the spec recommends that async servers pre-read the request
body
before invoking the app (either by default or as a configurable
option).
This is the best solution most of the time (but not for all
Christopher Stawarz ha scritto:
On May 7, 2008, at 4:44 AM, Manlio Perillo wrote:
[...]
I don't think this will solve the problem.
Moreover in your example you buffer the whole request body so that you
have to yield only one time.
Your example was:
def application(environ, start_res
nously" resumes the given request
(it will be resumed as soon as control returns to Nginx, when the
application yields something).
Note that the problem of resuming another request is easily solved
with greenlets, without the need to new extensions
(this is one of the reason
The WSGI PEP explicitly mention the PEP 325 (for the application
iterable close method).
Maybe this should be updated for the next WSGI spec, since Python 2.5
implements the PEP 342?
Regards
Manlio Perillo
___
Web-SIG mailing list
Web-SIG
rtant everywhere but UNIX.
This has the same problems that we have with wsgi.file_wrapper.
This is the reason, among other things, why the API in my implementation
uses ngx.connection_wrapper and ngx.poll_register
> [...]
Manlio Perillo
___
W
never considered.
In my implementation ngx.poll returns a function, so there should be no
problems.
Regards Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org
Christopher Stawarz ha scritto:
On May 7, 2008, at 4:20 AM, Graham Dumpleton wrote:
2008/5/7 Manlio Perillo <[EMAIL PROTECTED]>:
With your solution it seems that writing middlewares will not became
more
easy.
Part of what I was trying to say was that this needn't be exposed to
Manlio Perillo ha scritto:
[...]
The main problem I see with greenlet is that is is not yet stable (there
are some problems with the garbage collector) and that is is not part of
CPython.
This means that it can be not acceptable to write a PEP for a WSGI like
interface with coroutine
Christopher Stawarz ha scritto:
On May 6, 2008, at 6:17 AM, Manlio Perillo wrote:
I'm glad to know that there are some other people interested in
asynchronous application, do you have seen my extensions to WSGI in my
module for Nginx?
Yes, I have, and I had your module in mind
.connection_wrapper(wsgi.input)
...
ngx.poll_register(c, WSGI_POLLIN)
...
ngx.poll(1000)
Unfortunately I can not test if this is implementable.
I have some doubts.
> [...]
Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.py
our solution it seems that writing middlewares will not became
more easy.
Graham
Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/w
Phillip J. Eby ha scritto:
At 06:27 PM 5/5/2008 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
I think that it doesn't accept a relative URL, it accepts an absolute
path.
What do you mean?
environ = {}
setup_testing_defaults(environ)
url = '/a/b/'
That's a
e to yield, and is not very
good.
The solution is to use coroutines, and I'm planning to integrate
greenlets (from the pylib project) into the WSGI module for Nginx.
> [...]
Regards Manlio Perillo
___
Web-SIG mailing list
Web-SIG@pytho
Phillip J. Eby ha scritto:
At 11:03 PM 5/2/2008 +0200, Manlio Perillo wrote:
Hi.
I think that a function like (not tested):
def abs_url(environ, relative_url):
"""Return the absolute url"""
[...]
url += quote(relative_url)
return url
woul
1 - 100 of 238 matches
Mail list logo
