<br><br><div class="gmail_quote">On Thu, Sep 16, 2010 at 9:59 PM, Armin Ronacher <span dir="ltr"><<a href="mailto:armin.ronacher@active-4.com">armin.ronacher@active-4.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
On 9/17/10 3:43 AM, Ian Bicking wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not if you are working with the URL-encoded paths.<br>
</blockquote></div><br>
SCRIPT_NAME / PATH_INFO will always stay unencoded and the current spec requires the web3.script_name thing to only be provided if the server can safely provide that. So at least for the fallback, we are dealing with (properly latin1 decoded) non-URL encoded things. Can be changed of course.</blockquote>
<div><br>Yes, if we get rid of SCRIPT_NAME/PATH_INFO then the problem goes away. For servers without access to the unencoded value, reencoding those values doesn't actually lose any information over what we have now, and avoids any encoding issues. Servers with REQUEST_URI can at least attempt to reconstruct the encoded values.<br>
<br> </div><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">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cookie is weird. If that one header could be bytes, that'd be great...<br>
but special-casing Cookie/Set-Cookie is too hard/weird.<br>
</blockquote></div>
Special casing one header is indeed weird.</blockquote><div><br>Cookie is also the one header that can't be safely folded. It's just a messed up header, and requires hacky workarounds.<br><br> </div><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">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't know of any other header (or the status) that would reasonably<br>
cause a problem. And I'm not glossing over corner cases -- I'm<br>
generally very aware and concerned with legacy issues, and interacting<br>
with legacy systems. There just aren't any here except for the<br>
resolvable issues I've listed.<br>
</blockquote></div>
Technically speaking it would affect etags too, but I doubt anyone is using non-ASCII quoted strings there. A very funny header is btw the Warning header which actually can have any encoding:<br>
<br>
"The warn-text SHOULD be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. This decision MAY be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1.<br>
<br>
If a character set other than ISO-8859-1 is used, it MUST be encoded in the warn-text using the method described in RFC 2047 [14]."<br>
<br>
Doubt anyone is using that header though.<br></blockquote><div><br>The Title header (in Atompub) also suggests 2047, but that's essentially an ASCII conversion like URL quoting. It looks something like =?iso-8859-1?q?p=F6stal?=<br>
</div></div><br clear="all"><br>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>