Re: Bug#421820: libapache2-mod-musicindex: Incorrect url-encoding of &-sign
reassign 421820 apache
retitle 421820 ap_escape_uri() doesn't escape &-sign
thanks
On 5/1/07, Thibaut VARENE <varenet@debian.org> wrote:
On 5/1/07, M.H. ten Berge <tenbergemh@yahoo.com> 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,
ap_escape_uri(pool, uri));
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
http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/200705.mbox/browser
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
query).
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
(T_ESCAPE_SHELL_CMD|T_ESCAPE_PATH_SEGMENT|T_OS_ESCAPE_PATH|T_HTTP_TOKEN_STOP)
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.
HTH
T-Bone
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
Reply to: