On Fri, Jul 16, 2010 at 5:06 PM, Ian Bicking <span dir="ltr"><<a href="mailto:ianb@colorstudy.com">ianb@colorstudy.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Fri, Jul 16, 2010 at 4:47 PM, Tres Seaver <span dir="ltr"><<a href="mailto:tseaver@palladion.com" target="_blank">tseaver@palladion.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
> Basically all the internal strings are textish, so we're left with:<br>
<br>
</div>What do you mean by "internal"? Anything in the headers or the CGI<br>
environment is intrinsically "bytes-ish" to me. Do you mean that you<br>
want application programmers to have them transparently decoded? If so,<br>
we can make that the responsibility of the non-middleware framework /<br>
application.<br></blockquote></div><div><br>By internal I mean all the CGI variables that aren't representing HTTP, like SERVER_NAME.<br clear="all"></div></div></blockquote><div><br>Actually I was thinking SERVER_SOFTWARE, though SERVER_NAME is somewhat similar as it doesn't come from HTTP, it comes from server configuration.<br>
<br></div></div>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>