<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Sep 22, 2009, at 10:22 PM, Ian Bicking wrote:</div><div><div><div><blockquote type="cite">I propose we switch primarily to "native" strings: str on both Python 2 and 3.<br>[...]</blockquote><blockquote type="cite">All [...] headers will be treated as Latin1.</blockquote><div><br></div><div>I like this. I think it would be "cleaner" to use bytes for all these things, but it's not really important.&nbsp;Given that headers and such are generally going to be ASCII, this works fine, is easy to implement, and is convenient for users.</div></div><div><br><blockquote type="cite">I then propose that we eliminate SCRIPT_NAME and PATH_INFO.&nbsp; Instead we have:</blockquote><blockquote type="cite"><br>wsgi.script_name<br>wsgi.path_info (I'm not entirely set on these names)<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#0000DE"><br></font></font></blockquote><br></div><div>IMO it would be better to continue providing SCRIPT_NAME/PATH_INFO, as latin-1 decoded strings -- the same as the other keys, but mark them deprecated, and *also* provide wsgi.script_name / wsgi.path_info with the semantics you describe.</div><div><br></div><div>I'll also note that it's generally possible to create wsgi.script_name and wsgi.path_info in a CGI wrapper, given only SCRIPT_NAME and PATH_INFO. You merely have to assume that all '/' characters are real slashes, and should remain slashes instead of being quoted into %2F. This is guaranteed true for most servers out there (they will forbid invoking a CGI with %2Fs in the url.) So nobody should have any issues implementing the WSGI-container side of this proposal.</div><div><br></div><div>James</div></div></div></body></html>