Date: Wed, 11 Dec 1996 17:19:56 -0800 (PST)
From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
Reply-To: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
To: new-httpd@hyperreal.com
Subject: Re: 1.2b2
In-Reply-To: <58j9l2$mf7@re.hotwired.com>
Message-Id: <Pine.HPP.3.95.961211170157.15777B-100000@ace.nueva.pvt.k12.ca.us>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On 10 Dec 1996, Dean Gaudet wrote:

> Here's one I gave Alexei a long time ago and forgot about until now.  Hope
> he doesn't mind me posting his reply.

No, I don't. And I have some more thoughts, too. See below.

> On Fri, 16 Aug 1996, Dean Gaudet wrote:
> 
> > I'm still trying to get apache 1.1.1 to work at hotwired... and I'm running
> > into problems with PATH_INFO and SSI.  Here's an ssi fragment:
> > 
> > <!--#include virtual="/cgi-bin/env.cgi/path?query"-->
> > 
> > (env.cgi is just a debugging tool like printenv)
> > 
> > If I do that without your PATH_INFO patch (posted 7 Aug 1996 22:05:22 GMT)
> > it sets PATH_INFO = /path.  With the patch, PATH_INFO isn't set.
> > 
> > I'm willing to believe that I don't understand #include virtual... but
> > I think it should set PATH_INFO.  What's your take?

The reason has to do with backwards compatibility in #include
cgi. Thing is, the way NCSA httpd did it, #include cgi would set
PATH_INFO to the path info of the *original* request. In fact, you're
not allowed to hard code path info into an #include cgi request. So
Apache is back-compatible with this. But Apache also allows you to run
CGI scripts with include virtual (which NCSA didn't), which leaves a
dilemna.

I recognize that we should maintain backwards-compatibility where
possible. OTOH, I think that we defenitely should include the path
info somehow in this case.

Here's a path... er.. patch (*grin*) that is a general fix to the "new
PATH_INFO blues", including the problem reported a few days ago with
cgiwrap, and information getting lost. It sets a new env variable,
FILEPATH_INFO, to what PATH_INFO would have been under Apache 1.0 and
1.1. This is applicable both to CGI scripts run directly, and with
include virtual. It leaves SCRIPT_NAME and PATH_INFO as they are now
(in 1.2b2), which IMO is defenitely correct - especially since it
doesn't cause core dumps.

As the comment says, this should allow scripts to be written that are
compatible both with the old and new behaviors. Although IMHO, scripts
that make use of hard-coded filename path information are skating the
edge of disaster anyhow. Isn't this what SetEnv and its friends are
for?

Anyhow, here's the patch:

Index: util_script.c
===================================================================
RCS file: /export/home/cvs/apache/src/util_script.c,v
retrieving revision 1.29
diff -c -r1.29 util_script.c
*** util_script.c	1996/12/09 01:00:40	1.29
--- util_script.c	1996/12/12 01:18:09
***************
*** 236,241 ****
--- 236,252 ----
  	table_set (e, "PATH_INFO", r->uri + path_info_start);
      }
  	
+     /* Some CGI apps need the old-style PATH_INFO (taken from the
+      * filename, not the URL), so we provide it in a different env
+      * variable. CGI scripts can use something like (in Perl)
+      * $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
+      * to get the right information with both old and new
+      * versions of Apache (and other servers).
+      */
+ 
+     if (r->path_info && *r->path_info)
+ 	table_set (e, "FILEPATH_INFO", r->path_info);
+ 
      if (r->path_info && r->path_info[0]) {
  	/*
   	 * To get PATH_TRANSLATED, treat PATH_INFO as a URI path.


-- 
________________________________________________________________________
Alexei Kosut <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/