Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of gcaa-apreq-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: today's code review..
Date: Thu, 10 Mar 2005 17:40:47 -0500
Lines: 27
Message-ID: <87u0njktu8.fsf@gemini.sunstarsys.com>
References: <20050309230726.GA30466@roonstrasse.net>
 <87oedsmju4.fsf@gemini.sunstarsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
Cancel-Lock: sha1:HD23cV7hM7hkoWSdJtwdi435KZc=
Sender: news <news@sea.gmane.org>

Joe Schaefer <joe+gmane@sunstarsys.com> writes:

> Max Kellermann <max@duempel.org> writes:

[...]

>> - we should define what apreq_decode() does when it sees 8 bit ASCII
>>   escapes and unicode escapes in one string; the current behaviour
>>   (ignoring that) isn't a good solution. Maybe mark with that utf8
>>   flag? (could also solve the previous item on my list)
>
> Hmm, tough question.  If we start marking things as utf8, we need to
> do it accurately.  Can you be sure the unicode escapes don't come from
> some other UTF encoding?

IIRC the current url_decode implementation treats %uXXXX as the
numeric 16 bit codepoint, and it decodes that into a utf8 character.  
The %uXXXX comes from the escape() function of ecma-262 B.2.1,
so we can be confident about the utf8-ness of the result whenever
such an encoding is detected (in the query string, obviously).

But beyond that, I'm not sure what we can do right now in apreq.
The %uXXXX escapes are rare enough that I don't think we should
adjust our decode-APIs around them.

-- 
Joe Schaefer