On Fri, Jul 16, 2010 at 5:06 PM, Ian Bicking <span dir="ltr">&lt;<a href="mailto:ianb@colorstudy.com">ianb@colorstudy.com</a>&gt;</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">&lt;<a href="mailto:tseaver@palladion.com" target="_blank">tseaver@palladion.com</a>&gt;</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>
&gt; Basically all the internal strings are textish, so we&#39;re left with:<br>
<br>
</div>What do you mean by &quot;internal&quot;?  Anything in the headers or the CGI<br>
environment is intrinsically &quot;bytes-ish&quot; 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&#39;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&#39;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>