At 09:34 AM 12/24/2008 +1100, Graham Dumpleton wrote:
Have you read:
http://www.wsgi.org/wsgi/Amendments_1.0
As much as could be done was worked out quite a while back. I don't
quite understand why PJE is ignoring/forgetting about that list in the
amendments page.
Because I'm getting
At 09:30 AM 11/18/2008 +1100, Graham Dumpleton wrote:
I would be for (1) errata or amendment as reality is that there is
probably no WSGI implementation that disallows an argument to
readline() given that certain Python code such as cgi.FieldStorage
wouldn't work otherwise.
Please note that
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 change it to have readline(hint) and expand
At 04:23 AM 2/18/2008 -0800, est 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
At 04:57 PM 7/28/2008 -0700, Donovan Preston wrote:
On Jul 28, 2008, at 12:52 PM, Etienne Robillard wrote:
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:
snip
So is WSGI really synchronous? How
At 12:21 AM 7/23/2008 +0200, Irmen de Jong wrote:
Tibor Arpas wrote:
Hi,
I'm quite new to python and I ran into a performance problem with
wsgiref.simple_server. I'm running this little program.
[...]
I get many hundreds of responses/second on my local computer, which is fine.
But when I
At 11:35 AM 7/8/2008 -0700, Donovan Preston wrote:
On Jul 7, 2008, at 6:11 PM, Phillip J. Eby wrote:
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of
wsgi
that specifies how to get, set, and list request local storage
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 application API. See:
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.
By the way, a middleware that is responsible for user authentication:
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of wsgi
that specifies how to get, set, and list request local storage, and
for people to use that instead of the threadlocal module.
I don't follow why you wouldn't just put that
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 also an absolute path. Try
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
would be an useful addition to the wsgiref.util module.
What do you think?
At 11:41 AM 3/25/2008 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 11:04 AM 3/25/2008 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
It says that in versions of Python where 'str is unicode' (i.e.
Jython, IronPython, and Python 3000), then the specification
should be read to define string
At 09:37 AM 3/6/2008 +1100, Graham Dumpleton wrote:
You probably need to explain the second half of that sentence a bit
better. From memory the WSGI 1.0 specification says that for an
iterable, the headers should be sent upon the generation of the first
non empty string being yielded. How does
At 03:22 PM 1/24/2008 +0100, Manlio Perillo wrote:
Let's suppose that the request uri is /example/login/.
For the main application, SCRIPT_NAME is /example.
For the application at /login, SCRIPT_NAME is /example/login.
My problem is that I want, in the page generated by login application,
return
At 09:15 AM 1/23/2008 -0800, Robert Brewer wrote:
I consider it a bug in both, and the difficulty level of changing the
CGI behavior really has no bearing on our decision to do better with
WSGI. I think it's important that we allow the full range of URI's to be
accepted. If you go and stick Apache
At 08:34 PM 1/17/2008 +0100, Manlio Perillo wrote:
Hi.
What is the rationale for Headers._headers being private?
The code was mostly a copy-and-paste job from email.Message, which
did the same. At one point, it might actually have been a subclass
of email.Message, and so it was required.
At 02:05 PM 1/15/2008 +, Chris Withers wrote:
Phillip J. Eby wrote:
Why would they need to? The logging module has its own registry of loggers.
getLogger('x.y.z') only creates a logger if it doesn't already exist...
You're only shifting the issue from taking loggers as arguments, to
logger
At 05:15 PM 1/14/2008 +, Chris Withers wrote:
Phillip J. Eby wrote:
At 02:03 PM 12/21/2007 +, Chris Withers wrote:
I think I'm missing something: what in the logging package makes
you log by which module issued the message?
That's the conventional usage: modules that use logging usually
At 04:15 PM 12/26/2007 +1100, Graham Dumpleton wrote:
On 26/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote:
By the way: isn't it better to first release a WSGI 1.1 before
jumping to a (incompatible) WSGI 2.0?
Better for whom
At 09:36 AM 12/27/2007 +1100, Graham Dumpleton wrote:
Due to this inactivity at least, some I guess would like to see the
1.1 specification created or at least an amendment to 1.0 to at least
adjust points in the original specification that were in hindsight
wrong or impractical, plus allow for
At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote:
By the way: isn't it better to first release a WSGI 1.1 before
jumping to a (incompatible) WSGI 2.0?
Better for whom, and for what purpose?
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG:
At 09:50 PM 12/18/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 09:06 PM 12/17/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
This is precisely why WSGI doesn't really have any
configuration defined, because the whole idea is that it should
be as plug-and-play
At 11:51 PM 12/18/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 10:10 PM 12/18/2007 +0100, Manlio Perillo wrote:
Ok.
Here I would just say that when someone install something on its
system, it should at least know what he is doing.
And I repeat: you're welcome to your opinions
At 07:33 PM 12/17/2007 +0100, Manlio Perillo wrote:
Ian Bicking ha scritto:
[...]
The user shouldn't have to anticipate what an application can or should
do, beyond what the spec says.
I disagree.
The intent of mod_wsgi for nginx, among other things, is to have an
integrated deployment
At 09:06 PM 12/17/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
This is precisely why WSGI doesn't really have any configuration
defined, because the whole idea is that it should be as
plug-and-play as possible. Server-level configuration options
are a liability to be avoided
At 02:40 PM 12/12/2007 -0600, Ian Bicking wrote:
Having the same header show up in
multiple places seems dangerous (where the two values may not match,
especially if the request has one of those keys rewritten).
I agree -- this probably should be added to the WSGI spec, because
otherwise
At 12:08 PM 12/10/2007 +, Chris Withers wrote:
Hi All,
What's the best way to serve large files (say detailed images or pdfs)
from a wsgi app?
Is there special support for this?
That's what the iteration part of the protocol is for (well, and a
few other things). If you're not serving
So here are my recommendations so far for the addendum to WSGI *1.0*
for Python 3.0 (I expect we can be more strict for WSGI 2.0):
* When running under Python 3, applications SHOULD produce bytes
output and headers
* When running under Python 3, servers and gateways MUST accept
strings as
At 10:13 AM 12/7/2007 +1100, Graham Dumpleton wrote:
Has anyone had any thoughts about how WSGI is going to made to work
with Python 3?
From what I understand about changes in Python 3, the main issue seems
to be the removal of string type in its current form.
This is an issue as WSGI
At 08:08 PM 12/6/2007 -0500, Adam Atlas wrote:
On 6 Dec 2007, at 18:13, Graham Dumpleton wrote:
In Python 3 the default for string type objects will effectively be
Unicode. Is WSGI going to be made to somehow cope with that, or will
application instead be required to return byte string
At 01:25 PM 11/23/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 11:57 AM 11/23/2007 +0100, Manlio Perillo wrote:
Hi.
As I have written in a previous thread, I would like to use nginx
logging system in a WSGI application (of course the same is valid for
Apache)
A first problem
At 12:05 PM 11/10/2007 -0600, Ian Bicking wrote:
Jochen Kupperschmidt wrote:
Hi Ian,
when using your Paste suite and its HTTP server, I sporadically come
across a traceback related to a GeneratorExit. It does not seem to break
stuff, but it confuses me and fills up my log.
I put the
At 05:52 PM 10/15/2007 +0200, Manlio Perillo wrote:
Hi.
I'm implementing the start_response callable for Nginx mod_wsgi and I
have a few questions.
1) From the WSGI PEP it seems that an implementation is allowed to
*always* raise an exception when start_response is called with a not
At 06:21 PM 10/15/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 05:52 PM 10/15/2007 +0200, Manlio Perillo wrote:
Hi.
I'm implementing the start_response callable for Nginx mod_wsgi and I
have a few questions.
1) From the WSGI PEP it seems that an implementation
At 10:06 PM 10/15/2007 +0200, Manlio Perillo wrote:
Hi.
The only feature that remains to implement for nginx mod_wsgi is the
write callable.
The WSGI spec says:
In other words, before write() returns, it must guarantee that the
passed-in string was either completely sent to the client, or that
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 not support WSGI. The entire point of WSGI is to allow
legacy (i.e. already-written
At 06:25 PM 10/8/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
[...]
I don't think there's any point to having a WSGI extension for If-*
header support.
I have just found that the WSGI spec says:
...it should be clear that a server may handle cache validation via
At 08:23 AM 10/9/2007 +1000, Graham Dumpleton wrote:
On 09/10/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:25 PM 10/8/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
[...]
I don't think there's any point to having a WSGI extension for If-*
header support
At 01:07 PM 10/6/2007 +1000, René Dudfield wrote:
I think 'streaming' is good for speeding up web pages when processing
takes a while.
I'll explain why...
Say your page takes 0.2 seconds to process.
If you wait until 0.2 seconds is up, then the first bytes that will
come to the browser will
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.
If we were going to try to implement an asynchronous WSGI, what we would
*really* need to do is
At 01:34 PM 10/6/2007 +0100, Robin Bryce wrote:
There are plenty of stateless synchronous wsgi components out there
that I would like the option of serving as is. As the person choosing
the components in my wsgi stack I'm perfectly capable of deciding
whether such a synchronous app is safe in the
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,
there is no such existing framework that could meaningfully use
At 12:36 PM 10/5/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
[...]
Yep, but another argument in favor of getting rid of as much
statefulness from the protocol as we can. Making the status and headers
part of the return value entirely eliminates the question of when
At 11:57 AM 10/5/2007 -0300, Rob De Almeida wrote:
Phillip J. Eby wrote:
I mean that you can't write a WSGI 2.0 application using a single
generator function, because it has to return a tuple, not an
iterator. This will discourage people from thinking yield is a
good way to build up
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 legacy frameworks detecting
that they were in an incompatible hosting environment
At 05:34 PM 10/5/2007 +0100, Robin Bryce wrote:
Is there a means to support a non blocking read on wsgi.input ?
No. Some ideas have been proposed, but nobody has shown a practical
scenario where it is useful.
For it to be useful, you would have to have an asynchronous server
that is
At 07:38 PM 10/5/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
I still don't see how this is *useful*. What will the application *do*
with this information?
As an example (not tested) SQLAlchemy can implements a
RequestSingletonPool, that is the equivalend
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
wsgi-ish implementations which aim to
At 12:30 PM 10/4/2007 +1000, Graham Dumpleton wrote:
On 04/10/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
There is a problem here: a WSGI gateway is not allowed to send headers
until the app_iter yields a non empty string or the iterator
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 the iterator is exausted.
Argh. You're right. I forgot about that bit. It has been
At 03:47 PM 10/4/2007 +0200, Manlio Perillo wrote:
Ian Bicking ha scritto:
PJE wants to talk about WSGI 2. That's cool; I remind everyone that
there's a page to bring up issues you might want to discuss for 2.0:
http://wsgi.org/wsgi/WSGI_2.0
Feel free to add to, or discuss, issues on
At 03:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
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
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. That is, to allow
the application to do error handling for as long as possible before
At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote:
Your are making a critical decision here.
You are lowering the level of WSGI to match the level of average WSGI
middlewares programmers.
No, we're just getting rid of legacy cruft that's hard to support
correctly. There's a big difference.
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.
I thought that the current WSGI 2.0 draft was only, indeed, a draft.
That's correct. But eliminating
At 05:54 PM 10/4/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
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
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?
Why do you think it's useful?
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 error in
the application, because everything is done after the code returns.
That suggests to me that these sorts of errors should be handled by
changing the response
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 error in the
application, because everything is done after the code returns
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*. That requirement is not a
should but a must, and it does not
At 04:57 PM 10/3/2007 +0200, Manlio Perillo wrote:
A possibile solution can be to add an extension `x-wsgiorg.flush`, a
callable object that notify the WSGI gateway that it can flush the
headers (if they are not yet be sent) or the output buffer (Nginx has
this feature, however I have yet not
At 09:52 PM 10/3/2007 +0200, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
[...]
Now that I understand what this is for, I can explain why a WSGI
extension is not necessary to provide this feature. In a compliant WSGI
gateway, yielding an empty string from 'a-generator' is sufficient
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 for that
header field is defined as a comma-separated list [i.e., #(values)].
At 05:47 PM 10/1/2007 +0200, Manlio Perillo wrote:
Hi, I have another question with error handling.
The WSGI spec only says that applications *must* not generate hop-by-hop
headers, but says nothing on how a WSGI server should handle them.
In the previous version of nginx mod_wsgi I just ignored
At 10:27 PM 10/2/2007 +0200, Manlio Perillo wrote:
Robert Brewer ha scritto:
[...]
As you note, it's part of the HTTP spec that such headers
can be combined without changing the semantics. Here's a list of the
headers that need to be folded:
comma_separated_headers = ['ACCEPT',
At 11:03 AM 9/25/2007 +0200, Manlio Perillo wrote:
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.
wsgiref.validate is the closest thing available to a test suite.
At 12:54 PM 9/25/2007 +0200, Manlio Perillo wrote:
The WSGI spec says that start_response callable *must not* actually
transmit the response headers. Instead, it must store them.
The problem is that it says nothing about errors checking.
As an example the Apache mod_wsgi implementation only
At 11:45 PM 8/24/2007 -0700, Robert Brewer wrote:
However, and here's the rub, if nextapp() raises an
exception, **self.response is never bound**, and
therefore we have no handle to the object we need
to close. Note that this is not a middleware-only
problem; servers can run into this too.
The
At 02:08 PM 8/20/2007 -0700, Cliff Wells wrote:
Hi,
There's someone working on a mod_wsgi module for the Nginx HTTP
server/proxy and Nginx's author was asking if there is a diagram
somewhere outlining the WSGI protocol (I think perhaps he'd help if he
understood WSGI). I google'd a bit but came
At 12:53 AM 7/10/2007 +0100, Noah Slater wrote:
Hello,
I want to package the wsgiref package for Debian but am unsure what
text to use for the licence section of the package. The PSF recommends
the following text:
Not since Python 2.0, it hasn't. :) The source you got this from
should be
At 03:00 AM 7/10/2007 +0100, Noah Slater wrote:
http://www.python.org/download/releases/2.5/license/
This recommends the use of:
Python 1.6.1 is made available subject to the terms and
conditions in CNRI's License Agreement. This Agreement together with
Python 1.6.1 may be located on the
At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
This should be a collaborative effort, and I'm very open to
discussion at all levels of detail. Even if this flies at the highest
conceptual level, there are still several things I know of we would need
to nail down:
* States. For example, do we
At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
Potentially a Zope-style minimal event framework would work. Maybe
something like:
send_signal(signal_name, signal_data)
subscribe(signal_name, listener)
That was what I was wondering, too, except I was thinking it would be
sufficient to
At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
Seriously, though, this handles the notification but not the state
machine, which I think is critical to the effort. It also doesn't do any
error-handling for misbehaving subscribers, so not all subscribers are
guaranteed to run if there's an
At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
Phillip J. Eby wrote:
At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
Seriously, though, this handles the notification but not the state
machine, which I think is critical to the effort. It also
doesn't do any
error-handling
At 02:47 PM 6/25/2007 -0700, Robert Brewer wrote:
If I'm primarily a Pylons user, I'm used to starting my websites with
paster serve. In this case, paste.script would create a WSPBus object.
[It's up to the Paste developers whether to distribute their own
wspbus.py module, or to require one via
At 04:06 PM 6/3/2007 +1000, Graham Dumpleton wrote:
Should I just process string and buffer
objects as a sequence without complaint as required by specification,
I'd say yes. It's trivial for someone to use wsgiref.validate to
test their application, and it will tell them about this issue.
You
http://rack.rubyforge.org/
Interestingly, they take the approach we're talking about for WSGI 2.0, as
far as a call signature taking one argument and returning three.
The spec is brief and to the point, in part because of that simplicity, but
also because they're ignoring HTTP 1.1 and issues
At 11:08 PM 3/29/2007 -0400, James Y Knight wrote:
On Mar 29, 2007, at 10:41 PM, Phillip J. Eby wrote:
It's not clear if the app_iter must be used in the same thread as the
application. Since the application is blocking, presumably *it*
must be
run all in one thread. This should be more
At 06:52 PM 3/29/2007 -0400, James Y Knight wrote:
Perhaps a WSGI 1.1 fixing these issues would be a good idea?
I would personally rather see a WSGI 2.0 that also gets rid of
start_response(), write(), and perhaps adds better async support.
I suspect that the current approach to using yield
At 07:56 PM 3/29/2007 -0500, Ian Bicking wrote:
Do we want to discuss WSGI 2.0? I added a wiki page here to list
anything anyone wants to discuss for 2.0: http://wsgi.org/wsgi/WSGI_2.0
I've listed the things I can remember, and copying here:
start_response and write
At 11:29 AM 3/22/2007 +, Alan Kennedy wrote:
Strictly speaking, WSGI requires python 2.2,
because of iterators.
Actually, it doesn't. The pre-2.2 iterator protocol is to be used in such
cases:
http://www.python.org/dev/peps/pep-0333/#supporting-older-2-2-versions-of-python
At 04:52 PM 3/22/2007 +, Alan Kennedy wrote:
But if the users want their modern python applications to be
portable everywhere on WSGI, e.g. returning (iterable) files as ouput,
Actually, returning a file as output is a horrible idea, since it will
massively reduce throughput, due to
At 02:47 PM 3/13/2007 -0500, Ian Bicking wrote:
The open issues section has three issue. One is a matter of defining some
naming convention, and as long as people *try* to match up their
conventions it will work. The second has a proposed solution. The last
is merely aesthetic.
These are
At 04:15 PM 3/13/2007 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 03:14 PM 3/13/2007 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
I didn't understand what you were proposing, I think. I still don't
really know what get_file_storage means.
It would return a cgi.file_storage encoding
At 09:43 PM 3/6/2007 -0600, Ian Bicking wrote:
Phillip J. Eby wrote:
The wrapper (as with the wsgi file wrapper) simply puts a WSGI face on
a non-WSGI result body, converting it to an iterator of strings, and
holding other attributes known to the middleware or other application object
At 09:56 AM 2/9/2007 -0800, Titus Brown wrote:
On Fri, Feb 09, 2007 at 12:10:00PM -0500, Phillip J. Eby wrote:
- Yeah, multiprocess should probably be set false there, and
- multithreadedness should depend on whether the ThreadingTCPServer or
- whatever it's called is mixed in. (HTTPServer does
At 11:54 PM 2/8/2007 -0800, Titus Brown wrote:
Hi folks,
I just ran into an interesting sanity check problem, and I was hoping
you could all cross-check *my* sanity.
Should the WSGI environ variables 'wsgi.multithread' and
'wsgi.multiprocess' be set to 'True' in
wsgiref.simple_server.WSGIServer?
At 07:07 PM 1/28/2007 +, Alan Kennedy wrote:
[Graham Dumpleton]
Should a WSGI adapter for a web server which allows a mount point to
have a trailing slash specifically flag as a configuration error an
attempt to use such a mount point given that it appears to be
incompatible with WSGI?
At 08:38 AM 1/8/2007 -0800, Foobar BazBaz wrote:
I'm using wsgiref.simple_server running behind Apache.
(Created using wsgiref.simple_server.make_server)
I see:
wsgi.multiprocess is False
wsgi.multithread is True
wsgi.run_once is False
I'm surprised by the value of multithread, since it
At 10:08 AM 1/8/2007 -0800, Robert Brewer wrote:
You'll have to manually tell any WSGI server what environment it's running
in, because mod_proxy/mod_rewrite doesn't include that metadata by
default. There's probably a way to send a custom header from Apache up to
the WSGI server, but that
At 09:55 AM 12/22/2006 -0800, Guido van Rossum wrote:
(Also, wsgiref violates a couple of Python style guides that make me
not want to update it myself. Phillip promised he would clean it up
for distribution but never did,
I only have the vaguest recollection of you mentioning this, but can't
At 08:51 PM 12/20/2006 +, Sylvain Hellegouarch wrote:
[1] http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver.py
Guido, it does appear that this server implements chunked encoding if you:
1. Use a status of 200, 203, or 206
2. Don't include a Content-Length header
3. *Yield* each
At 06:36 PM 11/13/2006 -0700, L. C. Rees wrote:
A few examples are:
wsgiorg.parsed_cookie - The contents of 'HTTP_COOKIE' stored in a
Cookie.SimpleCookie instance
wsgiorg.start_request - The start_request function
Do you mean start_response? If so, what do you need it in the environ for?
At 07:45 PM 11/12/2006 -0800, Robert Brewer wrote:
Sessions have 1) been around forever, 2) have consistently been done
similarly for each implementation, and 3) already require interoperation
with third party code (database APIs), so introducing a common interface
would not introduce any
At 05:42 PM 10/31/2006 -0600, Ian Bicking wrote:
Phillip J. Eby wrote:
At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
Anyway, I've updated the spec:
http://wsgi.org/wsgi/Specifications/url_vars
http://wsgi.org/wsgi/Specifications/url_vars?action=diff
Is everyone happy with this version?
I
At 04:18 PM 11/1/2006 -0500, Luke Arno wrote:
What additional value comes from lending
authority to this convention (url vars)? Bah! ;)
Exactly my point. Let a thousand flowers bloom in other namespaces. :)
___
Web-SIG mailing list
Web-SIG@python.org
At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
One little question: if a dispatcher can never produce one of the kinds of
information (which happens for some of them), should they put in an empty
list/tuple or empty dict, or should they put in None for that item? I'm
currently saying they
At 12:25 PM 10/24/2006 +, Hans Then wrote:
Phillip,
-1 on this being middleware. If middleware wants to read the input,
it should copy it to a temporary file or StringIO, not remove it.
The simple, standard way to do something like this would be to have a
library routine like
1 - 100 of 190 matches
Mail list logo
