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?


Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to