Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <66A5B85A-E3E2-4C30-8978-921E448D5F77@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: mod_include: echo, entity encoding and UTF-8
Date: Sat, 18 Sep 2010 19:10:26 +0200

Hi all,

When the SSI tag below is handled, the value of the string output to  
the browser is entity encoded:

<!--#echo encoding="entity" var="MY_VAR"-->

This is done with a line that looks something like this:

/* PR#25202: escape anything non-ascii here */
echo_text = ap_escape_html2(ctx->dpool, val, 1);

The problem with the above is the parameter "1", which means that non- 
ASCII characters are entity encoded as html escape sequences, and in  
the process anything encoded with UTF-8 (and is not ASCII) breaks.

What I propose we do is change the value for v2.3+ as follows:

echo_text = ap_escape_html2(ctx->dpool, val, 0);

This allows UTF-8 character sequences to be passed through unchanged.

Past discussion in PR#25202 seems to revolve around backwards  
compatibility, though with v2.4+ we have the power to change this  
behaviour.

Does any cross site scripting risk result as the allowance of UTF-8  
character sequences? I understand not, but would like to confirm.

Regards,
Graham
--