Re: Bug#421820: libapache2-mod-musicindex: Incorrect url-encoding of &-sign
reassign 421820 apache
retitle 421820 ap_escape_uri() doesn't escape &-sign
On 5/1/07, Thibaut VARENE <email@example.com> wrote:
On 5/1/07, M.H. ten Berge <firstname.lastname@example.org> wrote:
> Package: libapache2-mod-musicindex
> Version: 1.1.5-2
> Severity: normal
> File paths containing an &-sign are not URL-encoded correctly.
> Example: the bar displays "http://host/Jazz%20&%20Swing/SomeAlbum/".
> This should have been Jazz%20%26%20Swing.
That's a bug I've been trying to fix already in the past and thought I
had. It seems ap_escape_uri() isn't doing what I thought it would, and
digging into apache source code doesn't help me figuring out a proper
solution, hence my cc-ing of debian-apache for help.
I currently encode all hrefs by doing ap_escape_html(pool,
for some reason, ap_escape_uri seems to properly escaping everything
but '&'. Can somebody point me at a proper fix?
After digging into apache source code and asking around, I believe
this is an apache bug, hence me reassigning it:
Check the "help with ap_escape_uri()" thread here
ap_escape_uri() (aka ap_os_escape_path()) properly escapes pretty much
everything (including the '?' sign to avoid it being interpreted as a
query) but *not* the '&' sign (usually part of a multi-arguments
I believe that the problem lays in the hash table in
src/os/netware/test_char.h (from apache 1.3.34). I don't know if this
is actually the hash table used or not, but if it is, '&' (0x26) is
masked with 0x01 (T_ESCAPE_SHELL_CMD) whilst for instance '?' (0x3f)
is masked with 0x0f
which actually makes more sense.
Somebody suggested I should rewrite my own ap_escape() function that
would also escape the '&' sign. That clearly sounds wrong to me, as I
believe this kind of function ought to be provided by apache itself,
and I believe this is the intent of ap_escape_uri().
Please also note that this bug affects apache 2.2 in debian.