[Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote: On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby <p...@telecommunity.com> wrote: The Python 3 specific changes are to use: * ``bytes`` for I/O streams in both directions * ``str`` for environ keys and values * ``bytes`` fo

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 11:06 AM, P.J. Eby wrote: > At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote: > >> On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby <> >p...@telecommunity.com> wrote: >> The Python 3 specific changes are to use: >> >> * ``bytes`` for I/O streams in

[Web-SIG] Last call for WSGI 1.0 errata/clarifications

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! ___ Web-SIG mailing

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 10:06 AM, P.J. Eby wrote: > So, unless somebody has some additional arguments on this one, I think I'm > going to stick with bytes output. I don't have a strong opinion on whether it should be bytes or strings -- I'll leave that discussion for people who know more about th

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

At 11:11 AM 9/23/2010 -0600, Jeff Hardy wrote: On Thu, Sep 23, 2010 at 10:06 AM, P.J. Eby wrote: > So, unless somebody has some additional arguments on this one, I think I'm > going to stick with bytes output. I don't have a strong opinion on whether it should be bytes or strings -- I'll leave

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 11:52 AM, P.J. Eby wrote: >> I do think input and output should be symmetric, though. If response >> headers are going to be bytes, then the request headers should be as >> well, or vice versa. The same arguments apply to both, after all. > > Actually, they don't.  There ar

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 11:17 AM, Ian Bicking wrote: > If these headers accidentally contain non-Latin1 characters, the error >> isn't detectable until the header reaches the origin server doing the >> transmission encoding, and it'll likely be a dynamic (and therefore >> hard-to-debug) error. >

Re: [Web-SIG] Last call for WSGI 1.0 errata/clarifications

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 P.J. Eby wrote: > 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 ma

Re: [Web-SIG] Last call for WSGI 1.0 errata/clarifications

At 02:51 PM 9/23/2010 -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 P.J. Eby wrote: > 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

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

At 11:17 AM 9/23/2010 -0500, Ian Bicking wrote: I don't see any reason why Location shouldn't be ASCII. Any header could have any character put in it, of course, there's just no valid case where Location shouldn't be a URL, and URLs are ASCII. Cookie can contain weirdness, yes. I would ex

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 3:23 PM, P.J. Eby wrote: > At 11:17 AM 9/23/2010 -0500, Ian Bicking wrote: > >> I don't see any reason why Location shouldn't be ASCII. Any header could >> have any character put in it, of course, there's just no valid case where >> Location shouldn't be a URL, and URLs