[Zope-dev] redirect burps on unicode URLs

[Wichert Akkerman]

On 3/1/10 15:09 , Christian Theune wrote:
> Hi,
>
> On 03/01/2010 02:28 PM, Martin Aspeli wrote:
>>
>> I'm with Wichert here.
>>
>> In most places, we tend to carry around unicode strings internally, and
>> only encode on the boundaries, e.g. when the URL is "rendered". I don't
>> see why redirect() can't have a sensible and predictable policy for
>> unicode strings, making life easier for everyone.
>>
>> If we think that non-ASCII URLs are illegal, then maybe we should
>> validate for that and throw an error. However, I don't think that's the
>> case (anymore?). In that case, passing a unicode object to the function
>> seems entirely consistent with other places, e.g. when we pass unicode
>> to the page template engine or return unicode from a view, which the
>> publisher then encodes before it's pushed down to the client.
>
> I opened a question in another part of the thread, but haven't gotten an
> answer yet. In my understanding, a Unicode string is not able to
> represent the structural properties of a URL in http scheme properly,
> thus encoding back to ASCII is not possible.
>
> Can someone confirm or disprove this?

I am not sure what you mean. On the wire you get a path component in a 
HTTP get request which is UTF-8 encoded and escaped. For example 
http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 
, which is a Japanese string if you decode it back to unicode. That 
encoding works fine in two directions, and all other properties used in 
the http scheme such as query strings and fragments work normally. Can 
you provide an example of something that might not work?

Wichert.