On Tue, Aug 11, 2009 at 6:25 PM, Graham Dumpleton <span dir="ltr">&lt;<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

2009/8/12 Henry Precheur &lt;<a href="mailto:henry@precheur.org">henry@precheur.org</a>&gt;:<br>
<div class="im">&gt; Using bytes for all `environ` values is easy to understand on the<br>
&gt; application side as long as you are aware of the encoding problem. The<br>
&gt; cost is inconvenience, but that&#39;s probably OK. It&#39;s also simpler to<br>
&gt; implement on the gateway/server side.<br>
<br>
</div>Use of bytes everywhere can be inconvenient on the gateway/server<br>
side, at least as far as end result for user.<br>
<br>
The specific problem is that WSGI environment is used to hold<br>
information about the original request, as CGI variables, but also can<br>
hold user specified custom variables.<br>
<br>
In the case of anything hosted via Apache, such as through mod_wsgi,<br>
mod_fastcgi, mod_fcgid, mod_scgi and mod_cgi(d), users can set such<br>
custom variables using the SetEnv directive. Thus one might say:<br>
<br>
  SetEnv trac.env_path /usr/local/trac/site-1<br>
</blockquote><div><br></div><div>Just to clarify, there specifically is no type restrictions on extension variables, which is any variable with a &quot;.&quot; in it.  The type restrictions are solely for ALL_CAPS keys.  You can put ints or unicode or whatever in other variables.  (Probably this doesn&#39;t make things any easier for mod_wsgi, though; at least for this example)</div>

</div><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a>  |  <a href="http://topplabs.org/civichacker">http://topplabs.org/civichacker</a><br>