2009/8/4 P.J. Eby :
>> 5. When running under Python 3, servers MUST provide CGI HTTP and
>> server variables as strings. Where such values are sourced from a byte
>> string, be that a Python byte string or C string, they should be
>> converted as 'UTF-8'. If a specific web server infrastructure is
At 10:38 AM 8/4/2009 +1000, Graham Dumpleton wrote:
1. When running under Python 3, applications SHOULD produce bytes
output, status line and headers.
This is effectively what we had before. The only difference is that
clarify that the 'status line' values should also be bytes. This
wasn't noted
At 10:48 AM 8/4/2009 +1000, Graham Dumpleton wrote:
2009/8/4 P.J. Eby :
> At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
>>
>> Would this be a new PEP or a revision? I think it should be a new
>> PEP, as WSGI 1 remains valid and the same as it always was, and PEP
>> 333 describes that.
>
> +1 fo
2009/8/4 Mark Ramm :
>> In summary, just seems more sane to have stuff in WSGI environment be
>> dealt with as UTF-8.
>
> This sounds good to me. Rack, Jack, and even java servlets seem to
> make this assumption without significant trouble, and if nearly all
> existing web servers do it internall
> Personally I don't believe we should be trying to support async
> servers in the WSGI specification. Leave it simple and cater for the
> predominant case rather than make it complicated just to support what
> is going to be a minority deployment. It was async servers that got
> the whole discussi
> In summary, just seems more sane to have stuff in WSGI environment be
> dealt with as UTF-8.
This sounds good to me. Rack, Jack, and even java servlets seem to
make this assumption without significant trouble, and if nearly all
existing web servers do it internally, that's seems like an even
b
2009/8/4 P.J. Eby :
> At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
>>
>> Would this be a new PEP or a revision? I think it should be a new
>> PEP, as WSGI 1 remains valid and the same as it always was, and PEP
>> 333 describes that.
>
> +1 for a new PEP, since we'd be able to drop a lot of cruft
2009/8/4 Ian Bicking :
> So... what about WSGI 2? Let's not completely drop the ball on this.
> I *think* we were largely in agreement; debate got distracted by some
> async stuff, but I don't think we particularly have to deal with that
> for WSGI 2. I think we do more than enough if we figure o
At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
Would this be a new PEP or a revision? I think it should be a new
PEP, as WSGI 1 remains valid and the same as it always was, and PEP
333 describes that.
+1 for a new PEP, since we'd be able to drop a lot of crufty examples
and explanations about
So... what about WSGI 2? Let's not completely drop the ball on this.
I *think* we were largely in agreement; debate got distracted by some
async stuff, but I don't think we particularly have to deal with that
for WSGI 2. I think we do more than enough if we figure out: WSGI in
Python 3, i.e., wit
10 matches
Mail list logo
