>Number: 2602 >Category: protocol >Synopsis: GET /cgi-bin/cginame%3Fparam=/path/filename does not replace >%3f before searching cginame?param... >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Mon Jul 13 01:40:01 PDT 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.2.1 >Environment: It's not an os problem, it's in the URL parser of apache (the %hh stuff for quoting special hex characters; HTTP standard says that URL's containing %hh quoted characters should be equivalent to the ones containing the characters themselves) >Description: If some browser requests a CGI using %3F instead of '?',Apache will parse the URL incorrectly and mistakenly search for a file containing '?' (e.g. cginame?xxx=yyy/zzz/ttt)
It is true that most browsers never use %3f with a cgi, but I need this in order to enable windoze clients to download generated files (otherwise windows will goof up the filename putting the cginame and a ? instead). So, I modified another cgi to yield url's like http://server.name.dom/cgi-bin/cginame%3Ffilename=/path/file.ext so that netscape for windoze will use file.ext instead of cginame? as the filename for d/l. But now apache says 404 not found, and a system trace says apache looks for cginame?filename=/path/file.ext and gets ENOENT. Did you fix this problem in 1.6.* ? If not, can you fix it ? >How-To-Repeat: Try to replace ? by %3f in a cgi name and load it like that, it will fail. >Fix: When parsing an URL, replace the %xx characters before anything else, especially before searching the cgi file. >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
