You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by jake buchholz <ja...@execpc.com> on 2000/11/27 18:22:17 UTC

mod_include/6896: POST data can no longer be sent to a .shtml

>Number:         6896
>Category:       mod_include
>Synopsis:       POST data can no longer be sent to a .shtml
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Mon Nov 27 09:30:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     jake@execpc.com
>Release:        1.3.14
>Organization:
apache
>Environment:
Linux xxx.xxx.xxx 2.2.16-RAID #16 SMP Wed Aug 30 14:35:57 EDT 2000 i686 unknown

egcs-2.91.66

Server Version: Apache/1.3.14 (Unix) mod_perl/1.24_01 PHP/4.0.3pl1 FrontPage/4.0.4.3

>Description:
A customer's web site contained a one-liner in their index.shtml:

	<!--#include virtual="/cgi-bin/cgiprog"-->

the CGI program is a self-contained perl CGI script that takes POST data (if
present) and acts on it.  If there isn't any POST data, it generates a form
that when submitted POSTs data back to itself (at the non-/cgi-bin URL).

This was working until the server was upgraded from 1.3.12 to 1.3.14, and it
now results in:

	Method Not Allowed
	The requested method POST is not allowed for the URL /index.shtml

Specifically allowing POST in the <Directory> via <Limit> didn't seem to do the
trick.  A partial workaround was to write a PHP script to take the place of the
.shtml:

	<?php
		$get="http://xxx.xxx.xxx/cgi-bin/cgiprog";
		$cal=$HTTP_POST_VARS["cal"];
		if ($cal != "") {
			$get .= "?cal=$cal";
		}
		$fd = fopen($get, "r");
		fpassthru($fd);
	?>

...however, all POST variables need to be takent into account in the PHP, and
any cookies aren't passed along either (because it's PHP that's really making
the request, not the viewer's browser...)

>How-To-Repeat:
http://www.evcal.com/jrw is a .shtml that includes /cgi-bin/jrw

http://www.evcal.com/cgi-bin/jrw will work, but the customer doesn't want the
cgi-bin portion of the URL to show.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]
 
 


Re: mod_include/6896: POST data can no longer be sent to a .shtml

Posted by jake buchholz <ja...@execpc.com>.
On Fri, Dec 01, 2000 at 12:29:46AM +0000, Tony Finch wrote:
> jake buchholz <ja...@execpc.com> wrote:
> >Server Version: Apache/1.3.14 (Unix) mod_perl/1.24_01 PHP/4.0.3pl1 FrontPage/4.0.4.3
> 
> What modules did you add to your 1.3.12 installation?

mod_perl, php4, and improved mod_frontpage...  i can try to dig up
exact version numbers if you need 'em...

> >A customer's web site contained a one-liner in their index.shtml:
> >	<!--#include virtual="/cgi-bin/cgiprog"-->
> >the CGI program is a self-contained perl CGI script that takes POST data (if
> >present) and acts on it.  If there isn't any POST data, it generates a form
> >that when submitted POSTs data back to itself (at the non-/cgi-bin URL).
> >This was working until the server was upgraded from 1.3.12 to 1.3.14, and it
> >now results in:
> >	Method Not Allowed
> >	The requested method POST is not allowed for the URL /index.shtml
> 
> I haven't tried to reproduce this problem, but from looking at the
> changelog and the differences between some of the relevant code I
> can't see how this can have happened. Can you reproduce the problem
> with a vanilla Apache installation -- no additional modules beyond
> the base distribution?

i haven't had time (nor do i expect to have time...  have a 40 page
paper and a seminar presintation to do for next week...  :(

> (I hope I can get this email out before we go for releasing 1.3.15 on
> Monday -- I'm on a plane at the moment and I'll be on vacation this
> weekend with strictly limited connectivity.)

sorry to rain on 1.3.15, but this thing was really unexpected...  i
never even figured that anyone would have done this sort of thing
until the trouble report came in from a customer (who was presenting
the site before investors that day...  yikes...)

the only thing i really found on bugs.apache.org that remotely
resembled this is from PR 1759...

-- 
Jake Buchholz, Senior Systems Administrator     :           /~\
Hosting Solutions Lead R&D Engineer             :    ASCII  \ /  Against
CoreComm, formerly Voyager.net, formerly ExecPC :   Ribbon   X   HTML
GnuPG (PGP5/6) and PGP 2.6.2 pub keys available : Campaign  / \  Mail