You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Andrew Wilson <aw...@hyperreal.com> on 1995/12/23 16:21:13 UTC

mod_cgi.c (un)smartness (fwd)

I've verified this.  Richard originally gave us the r0ng URL to
gosee.  The correct URL exhibiting this weirdness is:

    http://www.pi.se:8000/cgi-bin/test-location.sh

all other comments in the message stand.  The patch in the mail is
a bit bogus.  If this is a fix at all then the whole if (0 && ...)
statement needs to be pulled.  I guess that this logic is here in
the original to save a hit to the server, but right now it's breaking
stuff.

It may be that the original will work as 'expected' when Apache
starts sending Base: information which browsers can interpret as
the URL from which to make all links relative.

My limited understanding is that Base: (or whatever) isn't going
to be a feature of webservers for quite a while.  So what's best to
do in this case, patch it?

Ay.

Forwarded message:
> From levitte@adm.pi.se  Thu Dec 21 04:57:43 1995
> Message-Id: <19...@wagner.adm.pi.se>
> To: apache-bugs@apache.org
> Cc: staff@adm.pi.se, assar@nada.kth.se
> Subject: mod_cgi.c (un)smartness
> X-Mailer: Mew version 1.00.4 RL on Emacs 19.30.1
> Mime-Version: 1.0
> Content-Type: Text/Plain; charset=us-ascii
> Date: Thu, 21 Dec 1995 13:57:22 +0100
> From: Richard Levitte <le...@adm.pi.se>
> 
> OS: SunOS 4.1.3
> Httpd version: 1.0.0
> modules.c is replicated at the end of this message.
> 
> Someone has inserted a "smart" condition in mod_cgi.c.  It parses the
> output from the called script for the header "Location:", and if the
> value starts with a slash, it takes that page and sends it back to the
> browser instead of sending the "Location" header on.  This is probably
> a handy hack, EXCEPT if the page mentioned in the "Location:" header
> contains a relative link.  In that case, the browser gets confused.
> 
> Check the following URL: http://www.pi.se/cgi-bin/test-location.sh
> 
> The contents of http://www.pi.se/cgi-bin/test-location.sh are:
> 
>   #! /usr/local/bin/bash
> 
>   echo 'Location: /~levitte/test-location.html'
>   echo ''
> 
> And the contents of /~levitte/test-location.html are:
> 
>   <html>
>   <head><title>FOO</title></head>
>   <body><h1>FOO</h1><a href="index.html">press here!</a></body>
>   </html>
> 
> When I try this, the browser will think that the URL for that HTML
> page is http://www.pi.se/cgi-bin/test-location.sh, and when I move the
> mouse pointer over the link "Press here!", the browser shows me
> http://www.pi.se/cgi-bin/test-location.html, which isn't what was
> expected.
> 
> The patch to fix this bug simply removes the condition that causes it:
> 
> *** mod_cgi.c.orig	Thu Dec 21 11:41:11 1995
> --- mod_cgi.c	Thu Dec 21 11:42:54 1995
> ***************
> *** 307,313 ****
>   	
>   	location = table_get (r->headers_out, "Location");
>   
> !         if (location && location[0] == '/' && r->status == 200) {
>   	  
>               /* Soak up all the script output */
>   	    hard_timeout ("read from script", r);
> --- 307,316 ----
>   	
>   	location = table_get (r->headers_out, "Location");
>   
> ! 	/* This test must NEVER succeed!  Browsers get confused!
> ! 	   Therefore, i inserted `0 && ' so the test will always fail
> ! 	   /Richard Levitte <le...@pi.se> */
> !         if (0 && location && location[0] == '/' && r->status == 200) {
>   	  
>               /* Soak up all the script output */
>   	    hard_timeout ("read from script", r);
> 
> +--------------------------------------------------------------------+
> ! Richard Levitte, support @pi.se   ! tel: int+46-8-783 20 44        !
> ! Box 100 56                        ! fax: int+46-8-783 20 46        !
> ! S-100 55  Stockholm               ! Internet: levitte@adm.pi.se    !
> ! SWEDEN                            !                                !
> +-<a href="http://www.pi.se/~levitte/">A few words about myself</a>--+
> P.S.  modules.c:
> /* modules.c --- automatically generated by Apache
>  * configuration script.  DO NOT HAND EDIT!!!!!
>  */
> 
> #include "httpd.h"
> #include "http_config.h"
> 
> extern module core_module;
> extern module mime_module;
> extern module access_module;
> extern module auth_module;
> extern module negotiation_module;
> extern module includes_module;
> extern module dir_module;
> extern module cgi_module;
> extern module userdir_module;
> extern module alias_module;
> extern module common_log_module;
> extern module asis_module;
> extern module imap_module;
> 
> module *prelinked_modules[] = {
>   &core_module,
>   &mime_module,
>   &access_module,
>   &auth_module,
>   &negotiation_module,
>   &includes_module,
>   &dir_module,
>   &cgi_module,
>   &userdir_module,
>   &alias_module,
>   &common_log_module,
>   &asis_module,
>   &imap_module,
>   NULL
> };
> 


Re: mod_cgi.c (un)smartness (fwd)

Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sat, 23 Dec 1995, Andrew Wilson wrote:

> I've verified this.  Richard originally gave us the r0ng URL to
> gosee.  The correct URL exhibiting this weirdness is:

I disagree that it's weirdness. It's what's commonly known as a feature. 
At least, I consider it suck. To recap (unless I missed something), the
'unsmartness' is that when a CGI returns sends

Location: /whatever

the server internally redirects to /whatever, sends /whatever, and then 
(golly gosh gee whiz) relative links don't work. Complaining about this 
is sorta like wrapping batteries in aluminum foil, putting them in the 
freezer to 'preserve' them, and then complaining to the manufactuerer of 
the freezer when the batteries don't work.

I mean, really. If you don't want that to happen, don't do it. No one is 
forcing anyone to use internal redirects. If you use them, presumably you 
can understand what they do, and write your scripts and pages 
accordingly. If it breaks relative links (which it does, in many cases), 
then don't use relative links!

This feature is *very* handy, and I use it all the time.

--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------