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