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
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
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
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
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:
> 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:
> 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:
>
>> 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 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
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
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
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.
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
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
__
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
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:
> 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
>>>
>&
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
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:
*
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.
>>>>
>>>>
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:
> [...]
>> 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
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
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
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.
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
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
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,
>> >
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 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
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
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
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:
> 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
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
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
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
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
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
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
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:
> [...]
>> 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 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
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
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:
> [...]
>> 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:
> [...]
> --- 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:
> 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
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'
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
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
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
le
implementation for Apache) since his module has been an invaluable
resource for me.
ngx_http_wsgi_module contains some pieces of code taken from mod_wsgi.c.
I hope that nginx wsgi module will help to make WSGI more "asyncronous
app" friendly, since the current implementation seems to
k function when
the result is available:
conn.execute("SELECT * FROM test", query_callback)
def query_callback(row):
write(row[...])
2) Can be implemented in mod_wsgi, however my problem is that I can't
figure out how the application can yield some data available after a
ca
Jean-Paul Calderone ha scritto:
> On Tue, 18 Sep 2007 13:39:23 +0200, Manlio Perillo <[EMAIL PROTECTED]> wrote:
>> [snip]
>>
>> 1) should be very simple to implement, and it is easy to understand how
>> to use it.
>>
>> As an example, we can use some A
Hi.
I'm searching for a generic test suite for WSGI implementations.
Any suggestions?
I will use it to test my mod_wsgi implementation for nginx.
Thanks Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org
e then 3 digits, without reporting an error.
Again, is this the intented, conforming, behaviour?
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/
raise an exception.
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/mailman/options/web-sig/archive%40mail-archive.com
d-value to the first, each separated by a comma."""
?
Ngins does not do this (and I don't know what Apache does).
Another question: when an header has an empty field value, what should
be set in the environment: an empty string or None?
Thanks Manlio Perillo
Manlio Perillo ha scritto:
> [...]
> As an example Nginx stores all the headers in a associative array,
> where, of course, only the "last seen" headers appears.
>
A correction: Nginx stores "raw" headers in a list of key/value pairs,
and not in an associativ
Phillip J. Eby ha scritto:
> At 09:30 PM 10/2/2007 +0200, Manlio Perillo wrote:
>> The HTTP 1.1 protocol (section 4.2) says that:
>> """Multiple message-header fields with the same field-name MAY be
>> present in a message if and only if the entire field-value
some of these headers are response headers, and it is
responsibility of the WSGI application to properly folding them, and not
of the WSGI gateway.
> The only tricky one is Cookie, because e.g. Konqueror sends them on
> multiple lines, but they're not foldable.
>
> See http://kristol.org
Phillip J. Eby ha scritto:
> At 10:03 PM 10/2/2007 +0200, Manlio Perillo wrote:
>> Manlio Perillo ha scritto:
>> > [...]
>> > As an example Nginx stores all the headers in a associative array,
>> > where, of course, only the "last seen" headers appea
the
> header lines to the client. If you're only taking the last one, your
> gateway is non-compliant.
>
You are right, sorry.
I forgot that start_application returns a list, and not a dict.
The current implementation of mod_wsgi is compliant here, and the
headers are combi
Manlio Perillo ha scritto:
> Phillip J. Eby ha scritto:
>> [...]
>>> Note that some of these headers are response headers, and it is
>>> responsibility of the WSGI application to properly folding them, and not
>>> of the WSGI gateway.
>> On the contrar
e WSGI application.
In case of nginx mod_wsgi, the validation can be done by Nginx, but for
generic WSGI applications this can be done by a middleware.
I don't know if this feature is feasible, since I have not yet
implemented it, so I would like t
ange the response
code from 200 (OK) to 304 (Not Modified).
If I'm right, the current WSGI spec does not forbids or allows this.
> That is, sending an
> internal error message to the browser and logging details of the problem.
>
Regards Manlio Perillo
__
Phillip J. Eby ha scritto:
> At 07:03 PM 10/3/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > Thinking about this made me realize that WSGI 2.0 isn't going to be
>> able
>> > to validate *anything* about a response by raising an
Manlio Perillo ha scritto:
> [...]
> Note that in Nginx, unlike Apache, an output buffer can process a
> partial buffer,
Sorry, this is not correct.
The only difference from Apache, here, is that the data is written
asynchronously.
Manli
app_iter yields a non empty string or the iterator is exausted.
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:24 PM 10/3/2007 +0200, Manlio Perillo wrote:
>> WSGI already
>> states that the WSGI gateway should not buffer the data).
>
> It does not state that at all. It states that a gateway *must not delay
> the transmission of any block*. T
?
This can be done in WSGI 1.0 (since I can call start_response in the
app_iter generator) but cannot be done in WSGI 2.0.
A possibile solution for WSGI 2.0 is to add a wsgi.response_error exception:
raise environ['wsgi.response_error'](status='404 Not Found)
However there is
Phillip J. Eby ha scritto:
> At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > [...]
>> >> There is a problem here: a WSGI gateway is not allowed to send headers
>> >> until the app_iter yields a non empty string or th
erver is asynchonous,
that is, the WSGI application is executed in the main process loop
of the server and the WSGI application can be paused after it yields
some data.
5) clarify some points in the WSGI 1.0 spec, as discussed in the latest
emails
>Ian
Regards Manlio Pe
est object, but
I don't know if this is possible.
Another solution is to setup the headers and call send_headers at the
same time, but in this way it is no more possible to raise an exception
when the application calls start_response with incorrect headers.
If I'm right this is th
> some data.
>
> It's always the case that a WSGI application can be paused after it
> yields data, even in WSGI 1.0.
I was not aware of this.
It may cause some problems to a unaware WSGI application the fact that a
new "handler&
t; async APIs.
No.
I have read a lot of archived messages, and all I have seen are
*discussions* about asynchronous extensions, but no working implementations.
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 04:10 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Graham Dumpleton ha scritto:
>> > [...]
>> >> The idea was to allow an application to change its mind about the
>> >> headers until it had committed to writing data. Tha
Phillip J. Eby ha scritto:
> At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > [...]
>> >
>> > WSGI 2.0 does not have a start_response() callable in the first place,
>> > so none of these apply.
>> >
&g
tension and, more important, I will expose the nginx
event API to the WSGI application, writing an extension module.
The API will be low level, but once this API will be implemented, it
should be possibile to implement a common and standardized API, that
will works wit
r of iterations, and then will start at 0 again.
With nginx mod_wsgi this is not true, when a WSGI application set the
counter value to, say, 6, and a new request arrives, the application
associated with the previous request will now see the value 0, not 6,
when it will be unpaused.
&
Phillip J. Eby ha scritto:
> At 06:07 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> For nginx mod_wsgi I'm planning to add support to blocking
>> application,executing them in a thread (*but* there will be only one
>> thread per process, and the entire result will be
Phillip J. Eby ha scritto:
> At 06:37 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> To make an example (not tested), suppose that a WSGI application keeps a
>> global counter (as a thread specific data).
>>
>> When a new request arrives, the counter is reset to 0, and
Phillip J. Eby ha scritto:
> At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> But why you are against adding a new environ value (not necessary named
>> wsgi.asynchronous), that will explicitly state if the WSGI server will
>> interleave the WSGI application?
>
> W
Phillip J. Eby ha scritto:
> At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
>> >> But why you are against adding a new environ value (not necessary
>> named
>> &
quot;""As a side benefit, making the return a
3-tuple makes it impossible to write a WSGI app using a single generator"""?
And what do you mean by """getting rid of as much
statefulness from the protocol as we can"""?
Regards M
Phillip J. Eby ha scritto:
> At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > In other words, those flags were to support legacy frameworks detecting
>> > that they were in an incompatible hosting environment. However, IIUC,
>
'm writing a spec for a `wsgi.context_id`
extension, that will return a request specific identifier (in the same
way as it is done by os.getpid or thread.get_ident)
> Ian
>
Regards Manlio Perillo
___
Web-SIG mailing list
Web-SIG@python.
Manlio Perillo ha scritto:
> Ian Bicking ha scritto:
>> [...]
>>> Ok, here is more useful definition.
>>>
>>> If wsgi.asynchronous evaluates to true, then the WSGI application
>>> *will* be executed into the server main process cycle and thus the
&g
Phillip J. Eby ha scritto:
> At 05:14 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> >> Phillip J. Eby ha scritto:
>> >> > In other words, those flags were to support
Phillip J. Eby ha scritto:
> At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote:
>> That's to much chicken/egg for my tastes. All you are really saying is
>> that the CGI model covers the majority of 'common' use cases. I don't
>> know of anyone who would disagree with this. But as things stand all
>>
Phillip J. Eby ha scritto:
> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote:
>> As an example, the WSGI write callable cannot be implemented in a
>> conforming way in Nginx.
>
> ...unless you use a separate thread or process.
>
I'm insisting about asynchronous
Graham Dumpleton ha scritto:
> On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote:
>> Phillip J. Eby ha scritto:
>>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote:
>>>> As an example, the WSGI write callable cannot be implemented in a
>>>>
Phillip J. Eby ha scritto:
> At 05:48 PM 10/6/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote:
>> >> As an example, the WSGI write callable cannot be implemented in a
>> >> conforming w
Ian Bicking ha scritto:
> Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote:
>>>> As an example, the WSGI write callable cannot be implemented in a
>>>> conforming way in Nginx.
>>
Phillip J. Eby ha scritto:
> At 01:02 PM 10/8/2007 +0200, Manlio Perillo wrote:
>> Supporting "legacy" and "huge" WSGI applications is not really a
>> priority for me.
>
> Then you should really make it clear to your users that your Nginx
> module does
Graham Dumpleton ha scritto:
> On 08/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote:
>> Phillip J. Eby ha scritto:
>>> At 01:02 PM 10/8/2007 +0200, Manlio Perillo wrote:
>>>> Supporting "legacy" and "huge" WSGI applications is not really
iteration over the app_iter object, for optimization purpose
2) For a WSGI implementation embedded in an existing webserver, the
most convenient method to perform cache validation is to let the
server do it; however this requires to send the headers as soon as
start_response is called,
Thomas Broyer ha scritto:
> 2007/10/8, Manlio Perillo:
>> However there are two problems here:
>> 1) It is not clear if WSGI explicitly allows an implementation to skip
>>the iteration over the app_iter object, for optimization purpose
>> 2) For a WSGI implementat
.
>
You can always publish an addendum or errata to WSGI 1.0, or just WSGI 1.1
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
1 - 100 of 238 matches
Mail list logo
