On Thu, Sep 16, 2010 at 21:39, P.J. Eby p...@telecommunity.com wrote:
Or, to put it another way: splitting the spec into two 100% incompatible
versions is a bad idea for Python 3 adoption. With a WSGI 1 addendum, we
should be able to make it possible to put the same apps and middleware on 2
Am 16.09.2010 20:00, schrieb Ian Bicking:
On Thu, Sep 16, 2010 at 12:35 PM, Guido van Rossum
gu...@python.org
mailto:gu...@python.org wrote:
On Thu, Sep 16, 2010 at 10:01 AM, Ian Bicking
i...@colorstudy.com
mailto:i...@colorstudy.com wrote:
Well, reiterating some things
On Fri, Sep 17, 2010 at 10:36 AM, Georg Brandl g.bra...@gmx.net wrote:
Am 16.09.2010 23:07, schrieb James Mills:
- the web3 name
If there is any value in this PEP and we find something to decide on,
there is no reason this couldn't be WSGI 2. But until it's just
something a small part of
On Thu, Sep 16, 2010 at 6:41 PM, Armin Ronacher
armin.ronac...@active-4.com wrote:
4. The web3 spec says, In case a content length header is absent the
stream must not return anything on read. It must never request more
data than specified from the client. but later it says, Web3
On 09/17/2010 04:21 AM, Ian Bicking wrote:
Yes, if we get rid of SCRIPT_NAME/PATH_INFO then the problem goes away. For
servers without access to the unencoded value, reencoding those values
doesn't actually lose any information over what we have now, and avoids any
encoding issues.
It
Hi,
On 9/17/10 11:40 AM, And Clover wrote:
This is why I am continuing to plead for a 'script_name/path_info are
authoritative' flag in environ that applications can use to detect
situations where it is safe to go ahead and rely on them. I want to say
Unicode paths are supported if your
On 09/17/2010 02:03 PM, Armin Ronacher wrote:
In case we change the spec as Ian mentioned above, I am all for
a wsgi.guessed_encoding = True flag or something like that.
Yes, I'd like to see that. I believe going with *only* a
raw-or-reconstructed path_info, rather than having both path_info
At 03:43 PM 9/17/2010 +0200, And Clover wrote:
On 09/17/2010 02:03 PM, Armin Ronacher wrote:
In case we change the spec as Ian mentioned above, I am all for
a wsgi.guessed_encoding = True flag or something like that.
Yes, I'd like to see that. I believe going with *only* a
Hi,
On 9/17/10 5:42 PM, P.J. Eby wrote:
So, do you have an example of what some real-world code is going to *do*
with this information? i.e., what's the use case for knowing the precise
degree of messed-uppedness of the path? ;-)
Actually, I can see a couple of use cases. I have a blog that by
I don't like this proposal at all. Besides having to go through the bytes
craziness the design is pretty backwards for middleware and asynchronous
applications.
Even the proxy_and_timing_support example in the PEP is broken for async or
streaming apps - it won't return the proper time (since it
On Fri, 2010-09-17 at 19:47 +0300, Ionel Maries Cristian wrote:
I don't like this proposal at all. Besides having to go through the
bytes craziness the design is pretty backwards for middleware and
asynchronous applications.
We've acknowledged in other messages to this thread that the
On Fri, Sep 17, 2010 at 9:43 AM, And Clover and...@doxdesk.com wrote:
On 09/17/2010 02:03 PM, Armin Ronacher wrote:
In case we change the spec as Ian mentioned above, I am all for
a wsgi.guessed_encoding = True flag or something like that.
Yes, I'd like to see that. I believe going with
On Fri, Sep 17, 2010 at 1:02 PM, Ian Bicking i...@colorstudy.com wrote:
I would really like to see concerns over bad gateways not be used to keep
valuable information out of the spec. We want people to use well-configured
gateways that accurately represent requests. There are limits, e.g.,
On Fri, 17 Sep 2010, Ionel Maries Cristian wrote:
I feel this spec puts too much burden on applications - having to process
all those byte strings and even having to add Content-Length even for naive
buffered-body apps.
The Content-Length requirement is a big killer for me. I'm usually
On Fri, Sep 17, 2010 at 1:37 PM, chris.d...@gmail.com wrote:
On Fri, 17 Sep 2010, Ionel Maries Cristian wrote:
I feel this spec puts too much burden on applications - having to process
all those byte strings and even having to add Content-Length even for
naive
buffered-body apps.
The
Hi,
On 9/17/10 7:43 PM, Ian Bicking wrote:
I'm also not sure what motivated this particular change, but I don't
have any opinion one way or the other.
Motivation is that WSGI wants servers to do something like this:
if len(iterable) == 1 and content_length_header_missing:
On Fri, Sep 17, 2010 at 2:06 PM, Armin Ronacher armin.ronac...@active-4.com
wrote:
Hi,
On 9/17/10 7:43 PM, Ian Bicking wrote:
I'm also not sure what motivated this particular change, but I don't
have any opinion one way or the other.
Motivation is that WSGI wants servers to do something
17 matches
Mail list logo
