On 17/07/2005, at 6:16 PM, Ian Bicking wrote:
The pipeline itself isn't really late bound. For instance, if I was
to
create a WSGI middleware pipeline something like this:
server -- session -- identification -- authentication --
-- challenge -- application
... session,
On 30/04/2006, at 10:50 AM, Ian Bicking wrote:
Phillip J. Eby wrote:
At 07:48 PM 4/28/2006 -0500, Ian Bicking wrote:
One is not more complex than the other.
The implementation has more moving parts, but I was talking about
conceptual complexity.
The most common web servers do not match
How does one implement in WSGI an input filter that manipulates the request
body in such a way that the effective content length would be changed?
In the WSGI PEP it says:
CONTENT_LENGTH
The contents of any Content-Length fields in the HTTP request. May be
empty or absent.
Also, it
Alan Kennedy wrote ..
[Graham Dumpleton]
How does one implement in WSGI an input filter that manipulates the request
body in such a way that the effective content length would be changed?
The problem I am trying to address here is how one might implement using
WSGI a
decompression
Robert Brewer wrote ..
Graham Dumpleton wrote:
My understanding is that content encoding is different
to transfer encoding, ie., is not hop by hop in this
sense and that the same statements don't apply.
No, you're right. Content-Encoding: gzip is not hop-by-hop, and should
therefore
Another question on SCRIPT_NAME, PATH_INFO etc.
This time I am after information on what responsibilities an adapter for a
specific web server has in respect of removal and/or preservation of repeating
slashes in a request URI.
Take for example that a WSGI application is mounted at:
/wsgi/a
The WSGI specification doesn't really say much about chunked transfer encoding
for content sent within the body of a request. The only thing that appears to
apply is the comment:
WSGI servers must handle any supported inbound hop-by-hop headers on their
own, such as by decoding any inbound
Sidnei da Silva wrote ..
I'm not quite aware of the 100 Continue semantics, but I know that
applications which request Transfer-Encoding: chunked should *not*
expect a Content-Length response header, nor should the WSGI thingie
doing the 'chunking' need to know it in advance.
'chunked' is
Robert Brewer wrote ..
Graham Dumpleton wrote:
In CherryPy, when it sees that the Transfer-Encoding
is set to 'chunked' while parsing the HTTP headers,
it will at that point, even before it has called
start_response for the WSGI application, read in all
content from the body
When one is using CGI as a means of implementing a WSGI application,
although one would return content through the iterable returned from
the application or by calling write() method returned from
start_response(), one could actually write to sys.stdout directly as
well since that is where the
Thanks for all the input, gives me some things to think about.
On 23/03/07, Ian Bicking [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
In the case of sys.stdout, do people see it as being at least good
practice, if not required by specification, that the WSGI adapter
should ensure
On 30/03/07, Ian Bicking [EMAIL PROTECTED] 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:
...
Optional keys (removing)
On 06/04/07, James Y Knight [EMAIL PROTECTED] wrote:
On Apr 5, 2007, at 10:52 PM, Graham Dumpleton wrote:
On 06/04/07, James Y Knight [EMAIL PROTECTED] wrote:
What's the point of a switch? If the app didn't provide a content-
length, and you can't otherwise determine a content-length
On 07/04/07, Clark C. Evans [EMAIL PROTECTED] wrote:
On Fri, Apr 06, 2007 at 12:08:17PM +1000, Graham Dumpleton wrote:
| FWIW, in mod_wsgi I have now added a directive which allows one to
| enable within a specific context that chunked transfer encoding should
| be used for a response when
On 06/04/07, James Y Knight [EMAIL PROTECTED] wrote:
On Apr 5, 2007, at 10:08 PM, Graham Dumpleton wrote:
FWIW, in mod_wsgi I have now added a directive which allows one to
enable within a specific context that chunked transfer encoding should
be used for a response when a HTTP/1.1 client
The CGI specification allows for a CGI script to return a 'Location'
header which refers to a location within the local web server. Quoting
the RFC:
If the Location value is a path, then the server will generate the
response that it would have produced in response to a request
containing the URL
On 25/05/07, Ian Bicking [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
On 24/05/07, Ian Bicking [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
Does anyone think this would be nice extension for a WSGI adapter
written against current specification to implement even
On 27/05/07, Robert Brewer [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
The problem then as above is what does one do at
the boundary between a WSGI application and the
web server hosting it? Do you just always assume
a WSGI application provides an error page, or allow
some
The WSGI specification says:
When called by the server, the application object must return an
iterable yielding zero or more strings. This can be accomplished in a
variety of ways, such as by returning a list of strings, or by the
application being a generator function that yields strings, or by
On 04/06/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
On 28/06/07, Robert Brewer [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
Meanwhile, if you get a start call, you must be starting, right?
So why worry about the state? It'd be simpler to just use
before/during/after messages the way Twisted does. Your block
example could be replaced by
On 21/08/07, Cliff Wells [EMAIL PROTECTED] 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
On 21/08/07, Cliff Wells [EMAIL PROTECTED] wrote:
On Mon, 2007-08-20 at 18:42 -0400, Phillip J. Eby wrote:
Pardon me if any of this is already obvious, but from your
description it sounds like one or more parties might not be aware of
these points.
One of the parties (Igor, Nginx's
On 21/08/07, Cliff Wells [EMAIL PROTECTED] wrote:
On Tue, 2007-08-21 at 09:29 +1000, Graham Dumpleton wrote:
After dealing
with this email, found a message in my spam box from someone else
doing the same thing. This other persons name is Manlio Perillo. I
have pointed them
On 25/08/07, Robert Brewer [EMAIL PROTECTED] wrote:
Hi all,
I just found another corner case in the WSGI spec
that I thought I'd share so you all can check your
WSGI components for similar problems. Basically,
it comes down to error handling. Here's a simple
example:
class
that there is content, but the length isn't
known.
Graham
On 05/03/2007, at 10:28 AM, Graham Dumpleton wrote:
The WSGI specification doesn't really say much about chunked
transfer encoding
for content sent within the body of a request. The only thing that
appears to
apply is the comment:
WSGI
On 04/10/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
On 04/10/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
On 05/10/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
wsgi.asynchronous), that will
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
conforming way in Nginx.
...unless you use a separate thread or process.
I'm
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 a
priority for me.
Then you should really make it clear to your users that your Nginx
module
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.
I have just found that the WSGI spec says:
...it should
On 09/10/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
On 17/11/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Manlio Perillo ha scritto:
In these days I have to install a Trac instance.
Trac needs a TRAC_ENV variable, and it seems that the only ways to set
this variable is to:
1) Set the TRAC_ENV environment variable (CGI)
2) Use the
On 19/11/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Titus Brown ha scritto:
On Sun, Nov 18, 2007 at 09:03:23PM +0100, Manlio Perillo wrote:
- Titus Brown ha scritto:
- -
- - However I still consider remarkable that there is not a trac.wsgi
script.
- - Can this be caused by the
On 23/11/2007, Manlio Perillo [EMAIL PROTECTED] 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)
On 24/11/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
Whatever you do, please do not go releasing any distinct Python
module/package called 'mod_wsgi' as the Apache mod_wsgi code is all
set up around it being able to do that already, with the assumption
On 24/11/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
As for everything else, as suggested in a previous email, you would be
better off basing anything else beyond sys.stderr and wsgi.errors off
the Python 'logging' module. In doing this, nothing would be required
in the WSGI environment.
On 27/11/2007, Robert Brewer [EMAIL PROTECTED] wrote:
Chris Withers wrote:
Right, I'm curious as to how wsgi applications end up being
multi-threaded or multi-process and if they are, how they share
resources such as databases and configuration.
There's a couple of reasons I'm asking...
The second is a problem I see an app I'm working on heading towards.
The app has web-alterable configuration, so in a multi-threaded and
particular multi-process environment, I need some way to get the
other threads or processes to re-read their configuration when it has
changed.
In
On 30/11/2007, Chris Withers [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
For daemon mode, in mod_wsgi 2.0 there is also 'Process' reload
mechanism as an option. Just touching the main WSGI script file entry
point will cause just the processes for that daemon process group
On 30/11/2007, Chris Withers [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
package. You can if appropriate even use a combination of both modes.
So these would just be seperate sections in apache's config files?
For an example see:
http://blog.dscpl.com.au/2007/09/parallel-python
On 08/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
* When running under Python 3, servers MUST provide a text stream for
wsgi.errors
In Python 3, what happens if user code attempts to output to a text
stream a byte string? Ie., what would be displayed?
Also, if wsgi.errors is a text
Where does setting up 'logging' module configuration fall in all of
this and who/what should handle it?
I ask as I note that in the documentation for Pylons logging it says:
paster, when loading an application via the paster serve, shell or
setup-app commands, calls the logging.fileConfig
On 21/12/2007, Chris Withers [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
For me, it does feel like the responsibility of the server to
configure logging, and I think this is something that should be
documented somewhere. Afterall, as you guys have been discussing, it's
the server that
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The
specification should then also explicitly say that WSGI applications
should not redirect logging output to wsgi.errors or anywhere else. In
fact, if that was done, there would be no reason to have wsgi.errors in
the first place.
At
On 22/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
Graham Dumpleton ha scritto:
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The specification should then also explicitly say
that WSGI applications should not redirect logging
output to wsgi.errors
On 22/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
I can modify the code, so that:
- sys.stderr for the main interpreter goes to the main error log
- sys.stderr for subinterpreters goes to the error log declared in the
HTTP location where the WSGI application is
On 22/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
[...]
The more and more that this discussion goes on, the conclusion I am
coming to is that WSGI applications should simply not be using the web
server log files for application logging at all
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, and for what purpose?
As has been pointed out before, the main
On 24/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
On 22/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
[...]
The more and more that this discussion goes on, the conclusion I am
coming to is that WSGI applications should
On 27/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
On 29/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
Anyone else who has ever taken issue with the 1.0 specification,
please add any other things which you think would be reasonable.
Include links to mailing list archives where issue may have previously
been
On 29/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Hi.
Maybe I have already posted something like this.
From the WSGI spec it is not clear if a WSGI application is allowed to
call start_response and write from a separate thread.
For my WSGI implementation for Nginx, calling the write
Can the group mind provide some clarification on the following please.
1. The WSGI specification does not require that a WSGI adapter provide
an EOF indicator if an attempt is made to read more data from
wsgi.input than defined by request Content-Length. Is though a WSGI
adapter required to
On 25/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
1. WSGI gateways must always set environ[REQUEST_METHOD] to GET for HEAD
requests. Middleware and applications will not be able to detect the
difference between GET and HEAD requests.
2. For a HEAD request, A WSGI gateway must not iterate
On 25/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
If Apache mod_wsgi (the WSGI gateway) does then do this, ie.,
didn't iterate through the iterable and therefore didn't
return the content through to Apache, it would as explained
cause traditional Apache output
On 26/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
1. PEP 333 doesn't indicate that the size parameter for the read() method is
optional. Is it optional or required? If it is optional, is the default value
-1?
2. What are the semantics of environ[wsgi.input].read(-1) when
Content-Length
On 27/01/2008, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
[...]
I have brought up the issue of chunked encoding and mutating input
filters previously, whether they be implemented in Apache or as WSGI
middleware. For the outcome of that discussion see
On 28/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
Graham Dumpleton ha scritto:
On 27/01/2008, Manlio Perillo [EMAIL PROTECTED] wrote:
This is just a suggestion, but what about requiring that a WSGI
implementation calls the WSGI application only when all
On 28/01/2008, Graham Dumpleton [EMAIL PROTECTED] wrote:
On 28/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
On 26/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
As to your questions about read() with no argument, or with
traditional Python file like object
On 25/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
My application correctly responds to HEAD requests as-is. However, it doesn't
work with middleware that sets headers based on the content of the response
body.
For example, a gateway or middleware that sets ETag based on an checksum,
On 29/01/2008, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 29, 2008, at 1:36 AM, Brian Smith wrote:
1. The WSGI gateway must send the response headers immediately when
the application yields its first non-empty string.
2. When there is an 100-continue token in the request Expect:
As I think we all know, no one implements readline() for wsgi.input as
defined in the WSGI specification. The reason for this is that stuff
like cgi.FieldStorage would refuse to work and would just generate an
exception. This is because cgi.FieldStorage expects to pass an
argument to readline().
On 31/01/2008, Chris McDonough [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
As I think we all know, no one implements readline() for wsgi.input as
defined in the WSGI specification. The reason for this is that stuff
like cgi.FieldStorage would refuse to work and would just generate
On 31/01/2008, Chris McDonough [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
If the size argument is made mandatory, then it would parallel how
read() function is defined, but this in itself would mean
cgi.FieldStorage would break.
This is because cgi.FieldStorage actually calls
-archives.apache.org/mod_mbox/httpd-modules-dev/200801.mbox/browser
Graham
On 31/01/2008, Brian Smith [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
Effectively, if a 200 response came back, it seems to suggest
that the client still should send the request body, just that
it 'SHOULD
Jose Galvez wrote:
this is an interesting issue, because I would suspect that all our pylons
applications will have to be converted as well as the pylons base code. I
know that there is going to be a program which will automate the
translation, but not having used it I don't know what issues
Let me get this right. You are complaining that the WSGI 2.0 would
break your non standard extension which was never a part of the WSGI
1.0 specification to begin with.
I also find it interesting that in the very early days you were
pushing very very hard for WSGI 2.0 to be specified and you had
On 07/03/2008, Brian Smith [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
Brian Smith ha scritto:
Manlio Perillo wrote:
Fine with me but there is a *big* problem.
WSGI 2.0 breaks support for asynchronous applications (since you
can no more send headers in the app iter).
On 07/03/2008, Brian Smith [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
Anyway, WSGI 2.0 currently talks about returning a single
tuple containing status, headers and iterable. What if it
actually optionally allowed the response to itself be an
iterable, such that you could do
On 06/03/2008, Manlio Perillo [EMAIL PROTECTED] wrote:
But I have to say that:
1) the asynchronous model is the right model to use to develope
robust and scalable applications (expecially in Python).
No it isn't. It is one model, it is not necessarily the 'right' model.
The
On 07/03/2008, Manlio Perillo [EMAIL PROTECTED] wrote:
Is it true that Apache can spawn additional processes,
Yes, for prefork and worker MPM, but not winnt on Windows. See for
example details for worker MPM in:
http://httpd.apache.org/docs/2.2/mod/worker.html
By the way, I know there is
On 11/03/2008, James Bennett [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 8:37 AM, Mark Ramm [EMAIL PROTECTED] wrote:
I would definitely support the incusion of a JSON library in the
standard lib. And, I think that it should be simplejson which is
used by TurboGears, Pylons, and
On 11/03/2008, Alan Kennedy [EMAIL PROTECTED] wrote:
[Graham]
The problem areas were, different interpretations of what could be
supplied in an error response. Whether an integer, string or arbitrary
object could be supplied as the id attribute in a request. Finally,
some
Okay, thanks for all that. Now for next question.
So far we haven't addressed how wsgi.file_wrapper should work for
Python 3.0. Already in existing versions of Python usage of
wsgi.file_wrapper may be unclear in that there are portability
concerns between UNIX and Windows over fact that FILE
2008/4/7 Ronny Pfannschmidt [EMAIL PROTECTED]:
Hi,
since json-rpc and xml-rpc basically do the same
and the only difference is the content-type (json is more concise),
i propose to create a single xml/json-rpc module.
I did the a semilar proposal to stdlib-sig,
they told me to ask in
2008/5/6 Christopher Stawarz [EMAIL PROTECTED]:
(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
Can anyone confirm for me what the behaviour should be if someone
includes a newline in the value of a WSGI response header?
CGI specification would seem to disallow it and thus WSGI adapter
should by rights possibly produce an error if user code does it.
At the moment I know of no WSGI adapter
2008/6/12 Sylvain Hellegouarch [EMAIL PROTECTED]:
Can anyone confirm for me what the behaviour should be if someone
includes a newline in the value of a WSGI response header?
CGI specification would seem to disallow it and thus WSGI adapter
should by rights possibly produce an error if user
And what happens if you actually supply a content length in your response?
2008/7/22 Tibor Arpas [EMAIL PROTECTED]:
Hi,
I'm quite new to python and I ran into a performance problem with
wsgiref.simple_server. I'm running this little program.
from wsgiref import simple_server
def
FWIW, there was a past discussion on these issues on mod_wsgi list. I
can't really remember what the outcome of the discussion was. The
discussion is at:
http://groups.google.com/group/modwsgi/browse_frm/thread/2471a1a71620629f
Graham
2008/11/13 Andrew Clover [EMAIL PROTECTED]:
It would be
2008/11/16 Ian Bicking [EMAIL PROTECTED]:
We need to make a revision to the WSGI spec to say that
environ['wsgi.input'].readline takes an optional size argument. It always
does in practice (except in wsgiref.validate.validator, rendering that
validator useless), and is required to in
2008/11/18 Tres Seaver [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manlio Perillo wrote:
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
2008/11/22 Randy Syring [EMAIL PROTECTED]:
I am looking for opinions and thoughts on best practice for limiting file
upload size. I have a few considerations:
Ultimately, I would want my application with my method of handling forms to
be able to give the user a message that the file size was
2008/11/28 Robert Brewer [EMAIL PROTECTED]:
Brian Smith wrote:
Randy Syring wrote:
Hopefully you can clarify something for me. Lets assume that the
client does not use '100 Continue' but sends data immediately, after
sending the headers. If the server never reads the request content,
2008/11/29 Luca Tebaldi [EMAIL PROTECTED]:
Hi,
should I build a client for web services that require authentication based
on a ca (pem and crt), I'm trying to use soappy but not work... someone have
any idea or can tell me where to find a tutorial?
More appropriate forum for stuff related to
2008/12/13 Ian Bicking i...@colorstudy.com:
Graham Dumpleton wrote:
Just noticed that although WSGI PEP doesn't specifically mention that
argument to read() on wsgi.input is optional, wsgiref.validate allows
calling read() with no argument.
From wsgiref.validate:
* That wsgi.input
2008/12/18 Manlio Perillo manlio_peri...@libero.it:
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
2008/12/24 Dmitry Vasiliev d...@hlabs.spb.ru:
Hi!
Currently wsgiref package in Py3k just broken so I've filled ticket
#4718 (http://bugs.python.org/issue4718). Actually there are more than
one ticket about the problem - see the link for details. In a comment to
the ticket Phillip said we
2009/3/28 Alan Kennedy a...@xhaus.com:
Dear all,
For those of you at PyCon, there is a WSGI Open Space @ 5pm today (Friday).
The sub-title of the open space is Does WSGI need revision?
An example: Philip Jenvey (http://dunderboss.blogspot.com/) raised the
need for something akin to what
2009/3/30 Robert Brewer fuman...@aminus.org:
We had a smaller third meeting and answered more issues.
Those present at the third meeting:
* Mark Ramm (TG)
* Mike Orr (Pylons)
* Bob Brewer (CherryPy)
* Glyph Lefkowitz (Twisted)
* David Reid (Twisted)
* Jean-Paul Calderone (Twisted)
Based on any discussions at PyCon, can someone give a summary of any
conclusions drawn about how WSGI 1.0 should be implemented in Python
3.0.
The previous analysis of this is at:
http://www.wsgi.org/wsgi/Amendments_1.0
I realise it may be work in progress, but I note that work being done
on
2009/4/2 Robert Brewer fuman...@aminus.org:
Alan Kennedy wrote:
Hi Graham,
I think yours is a good solution to the problem.
[Graham]
In other words, leave all the existing CGI variables to come through
as latin-1 decode
As latin-1 or rfc-2047 decoded, to unicode.
and do anything new
2009/4/2 Bill Janssen jans...@parc.com:
Alan Kennedy a...@xhaus.com wrote:
Hi Bill,
[Bill]
I think the controlling reference here is RFC 3875.
I think the controlling references are RFC 2616, RFC 2396 and RFC 3987.
I see what you're saying, but it's darn near impossible, as a practical
2009/4/2 Graham Dumpleton graham.dumple...@gmail.com:
Is there going to be any simple answer to all of this? :-(
I am slowly working through what I think I at least need to do for
Apache/mod_wsgi. I'll give a summary of what I have worked out so far
based on the discussions and my own research
Using nginx as front end to Apache/mod_wsgi as an example:
On nginx side you would use:
proxy_set_header X-Url-Scheme $scheme;
and on Apache/mod_wsgi side, with Django 1.0 as an example, in WSGI
script file we would have:
import os, sys
sys.path.append('/usr/local/django')
2009/4/17 Robert Brewer fuman...@aminus.org:
On Thu, 2009-04-16 at 00:12 -0700, Graham Dumpleton wrote:
So, from where I sit, we have:
1. Many header values which are ASCII.
2. A few header values which are ISO-8859-1 plus RFC 2047.
3. A few header values which are URI's
2009/5/5 Armin Ronacher armin.ronac...@active-4.com:
Hello everybody,
I just recently started looking at supporting Python 3 with one of my
libraries
(Werkzeug), mainly because the MoinMoin projects considers using it which uses
the library in question. Right now what Werkzeug does is
2009/5/6 Ian Bicking i...@colorstudy.com:
Philip Jenvey brought this to my attention:
http://www.python.org/dev/peps/pep-0383/
It's a UTF8 encoding and decoding scheme that encodes illegal bytes in such
a way that you can decode to get the original bytes object, and thus
transcode to
1 - 100 of 237 matches
Mail list logo