Return-Path: Delivered-To: apmail-apache-bugdb-archive@apache.org Received: (qmail 16936 invoked by uid 500); 4 Oct 2000 18:00:06 -0000 Mailing-List: contact apache-bugdb-help@apache.org; run by ezmlm Precedence: bulk Reply-To: apache-bugdb@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list apache-bugdb@apache.org Received: (qmail 16896 invoked by uid 501); 4 Oct 2000 18:00:02 -0000 Date: 4 Oct 2000 18:00:02 -0000 Message-ID: <20001004180002.16894.qmail@locus.apache.org> To: apache-bugdb@apache.org Cc: apache-bugdb@apache.org, From: sinck@ugive.com Subject: Re: mod_cgi/543: "%2F" not allowed in VGI script PATH_INFO Reply-To: sinck@ugive.com The following reply was made to PR mod_cgi/543; it has been noted by GNATS. From: sinck@ugive.com To: apbugs@apache.org Cc: Subject: Re: mod_cgi/543: "%2F" not allowed in VGI script PATH_INFO Date: Wed, 4 Oct 2000 10:50:43 -0700 I ran into this with one of the typical offending URLs. My problem is that the script isn't even on my site. My 404 Error Document/script isn't being called. eg: http://127.0.0.1/blahblah%2f Throws a vanilla 404 page rather than the custom 404 Handler (that works). Should the 404 handler: ErrorDocument 404 /perl/wtf.cgi care that the lamer threw a %2f in the url? I don't think so, at least initially. I think the security isn't immediately compromised by letting the custom 404 fire, since the standard places for the variables (QUERY_STRING, PATH_INFO, etc) aren't in the 'normal' places. The 404 writer would have to deliberately be stupid. Not that that doesn't happen, of course. Thanks for your attention. David Sinck