Christopher Stawarz ha scritto:
(I'm new to the list, so please forgive me for making my first post a
specification proposal :)
Browsing through the list archives, I see there's been some
inconclusive discussions on adding better support for asynchronous web
servers to the WSGI spec. Since such
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 relative URL that's
On May 5, 2008, at 10:08 PM, Graham Dumpleton wrote:
If write() isn't to be returned by start_response(), then do away with
start_response() if possible as per discussions for WSGI 2.0.
I think start_response() is necessary, because the application may
need to yield for I/O readiness (e.g. t
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 as a potential provider of
the AWSGI interf
2008/5/7 Christopher Stawarz <[EMAIL PROTECTED]>:
> On May 5, 2008, at 10:08 PM, Graham Dumpleton wrote:
>
>
> > If write() isn't to be returned by start_response(), then do away with
> > start_response() if possible as per discussions for WSGI 2.0.
>
> I think start_response() is necessary, becau
This is a very interesting initiative.
However there are few problems:
- there is no support for chunked input - that would require having support
for readline in the first place, also, it should be the gateway's business
decoding the chunked input.
- the original wsgi spec somewhat has some suppo
