Return-Path: owner-new-httpd
Received: by taz.hyperreal.com (8.6.12/8.6.5) id JAA25791;
 Tue, 18 Jul 1995 09:40:22 -0700
Received: from cass41 by taz.hyperreal.com (8.6.12/8.6.5) with SMTP id
 JAA25783; Tue, 18 Jul 1995 09:40:17 -0700
Received: from cass39.ast.cam.ac.uk by cass41 with smtp
	(Smail3.1.29.1 #9) id m0sYFgn-000CM3C; Tue, 18 Jul 95 17:40 BST
Received: by cass39.ast.cam.ac.uk (Smail3.1.29.1 #9)
	id m0sYFgk-0003pVC; Tue, 18 Jul 95 17:40 BST
Message-Id: <m0sYFgk-0003pVC@cass39.ast.cam.ac.uk>
Date: Tue, 18 Jul 95 17:40 BST
From: drtr@ast.cam.ac.uk (David Robinson)
To: new-httpd@hyperreal.com
Subject: Re: QUERY_STRING & #exec cmd bugs
Content-Length: 877
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

>From: rst@edu.mit.ai (Robert S. Thau)
>Date: Mon, 17 Jul 95 12:20:49 EDT

>Hmmm... backslash-octal escaping doesn't work for me in the
>shell-escape context ("cat > /tmp/foo\000bar" gives me a file named
>/tmp/foo000bar; the backslash simply gets elided).  Are there other
>programs which will treat this sort of backslash escape correctly?
>(If not it seems silly to try to use it --- anything which really
>requires %00 to work correctly, it can always just use QUERY_STRING in
>the CGI context, or QUERY_STRING_UNESCAPED for SSI <!--#exec-->s).

Not a reasonable test; you can't have filenames with null characters!
And \xxx escapes aren't valid in shell redirections. (I know not why.)

It works ok in command arguments, which is it is used for a script. e.g.

echo 'foo\000bar' > file

works for me.

I suspect there is little demand for PATH_INFO_(UN)ESCAPED.


 David.