You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/03/12 16:19:32 UTC
DO NOT REPLY [Bug 17918] New: -
API method ap_escape_path_segment does not encode '&'
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17918>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17918
API method ap_escape_path_segment does not encode '&'
Summary: API method ap_escape_path_segment does not encode '&'
Product: Apache httpd-1.3
Version: 1.3.27
Platform: Sun
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: core
AssignedTo: bugs@httpd.apache.org
ReportedBy: bugzilla@c-est-simple.com
The api method 'ap_escape_path_segment' does not URL-encode the '&' character.
This means that if you use it in a custom apache module, you will not be able
to correctly encode an URL that contains parameter-value pairs separated
with '&'. The '&' will be left unchanged, and passing this URL as a value of a
parameter of another URL will lead to mistakingly take this unchanged '&' for a
parameter-name separator of the new URL.
RFC 1738 says that ';', '/', '?' are reserved characters in the path and search
components of an HTTP URL, but the BNF shows '&' as well.
It looks like the correct parameter-value separator should be ';' but we all
know it's almost never the case (I think the CGI perl modules handles it,
though).
The correction of this problem is rather simple:
in src/main/gen_test_char.c
replace (line 61 in 1.3.27 Solaris):
if (!ap_isalnum(c) && !strchr("$-_.+!*'(),:@&=~", c)) {
with
if (!ap_isalnum(c) && !strchr("$-_.+!*'(),:@=~", c)) {
and start the full compilation all over again.
The "test_char.h" generator (gen_test_char) will be modified, a new
test_char.h generated, and used in util.c with the needed values to have '&'
url-encoded by 'ap_escape_path_segment'
The 'ap_escape_path_segment' documentation, while short, says it is not used by
apache. Witch is probably why this was not an issue until now...
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org