Michael Sinz <Michael.Sinz@sinz.org> writes:
> Well, it fixes it by prepending the "./" to the element, much like
> my kludge patch, only with less overhead (same new allocation) and with
> the "./" prepended only if there is a ":" before any "/"
> So, yes, this looks like a good way to fix this. (My other way was to
> %3A the ":" but that is not needed by using the ap_os_escape_path() function.
I think this was a good decision by the Apache team. There
typically will be a slash before the colon, so escaping won't be
necessary. If there isn't, "./::" is shorter than "%3A%3A" and
has no semantic difference.
Did you run this test on Windows? As ap_os_escape_path is
documented to take "an OS path", I worry that a Windows version
of Apache might treat the backslash as an OS-specific directory
separator and helpfully map it to the forward slash used in
hierarchic URIs. I did not find such code in server/util.c nor
in os/win32/util_win32.c, but who knows whether it will be added
> Kalle Olavi Niemitalo wrote:
>> Another option would be to call ap_escape_path_segment and append
>> the slash only afterward, but then it would have to be appended
>> separately to both name and href, leading to more complex code.
> As I said, I tried that - but ap_escape_path_segment() does not deal with
> the ":" in any way.
I'm sorry about the misinformation.
Received on Sun Oct 23 07:52:56 2005
- application/pgp-signature attachment: stored