php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #13316 CGI dies (Premature end of script headers) with URLs with /x after script name
Submitted: 2001-09-15 05:46 UTC Modified: 2002-01-27 00:58 UTC
From: jobarr at herzeleid dot com Assigned:
Status: Not a bug Package: URL related
PHP Version: 4.0.6 OS: Windows 2000 SP1
Private report: No CVE-ID: None
View Developer Edit
 [2001-09-15 05:46 UTC] jobarr at herzeleid dot com 
I am using the binary from this site.
Anytime I access a PHP script with any characters after a / after the script name, it gives me an internal server error 500 and says "Premature end of script headers: c:/php/php.exe" in the error log.

What I mean is if I type "http://localhost/script.php/1" it will crash. I want to do this so I can avoid "http://localhost/script.php?test=1" for search engines.

It works fine in module mode though!!

I hope this makes sense...it is hard to explain =)

I am using apache 1.3.20.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-09-17 09:34 UTC] ahill@php.net 
I can conform this also occurs on linux 2.2.19.

Best regards,
Andrew
 [2001-10-15 17:42 UTC] edink@php.net 
It is not possible to handle such requests due to the limitiations of CGI protocol. PHP will not crash, it will just output:

Fatal error - Unable to open /site/root/script.php/1

which is not valid response and thus the error message. It's probably better that way than to reveal the full path of the script in question.

If you really want that functionality install PHP as web server module.
 [2001-10-15 19:42 UTC] jobarr at herzeleid dot com 
How is that a limitation of the CGI protocol?
It works with Perl as a cgi:
http://localhost/cgi-bin/printenv.pl/1
Or is that some how different because it is within the cg-bin directory? Perl is being run as a cgi, not a module.

These are outputted from printenv.pl:
PATH_INFO="/1"
PATH_TRANSLATED="c:\www\1"
REQUEST_URI="/cgi-bin/printenv.pl/1"
SCRIPT_FILENAME="c:/www/cgi-bin/printenv.pl"
SCRIPT_NAME="/cgi-bin/printenv.pl"
 [2001-10-15 19:59 UTC] edink@php.net 
If you install PHP as CGI under apache
you would typically put:

Action php-script /cgi-bin/php
AddHandler php-script .php

in httpd.conf. If I put:

Action printenv-cgi-script /cgi-bin/printenv.pl
AddHandler printenv-cgi-script .pe

I get the following for request:
http://host/test.pe/test

PATH_INFO="/test.pe/test"
PATH_TRANSLATED="/home/ek/projects/test.pe/test"
REQUEST_URI="/test.pe/test"
SCRIPT_FILENAME="/home/ek/projects/apache/cgi-bin/printenv.pl"
SCRIPT_NAME="/cgi-bin/printenv.pl"

How am I supposed to guess that I should open /home/ek/projects/test.pe for processing?
 [2002-01-27 00:58 UTC] sterling@php.net 
This is a limitation of CGI, plain and simple.
 [2002-07-15 22:12 UTC] phpbugs at mattholland dot com 
You can call it "bogus" all you want, but 1) this behavior *DOES* happen, and 2) it *IS NOT* any sort of "limitation of CGI". If you don't understand what's happening, just say so.

$PATH_INFO is definitely part of the cgi spec, of course. And it is definitely properly passed through to a cgi script written in Perl. If you write a three line script (call it, say, pathinfo.pl) which merely echoes back the value of $PATH_INFO, then access it with a url like http://myserver/cgi-bin/pathinfo.pl/some/more/stuff , it will dutifully report that $PATH_INFO contains "/some/more/stuff" . Try the same exact thing in PHP running as a cgi engine, you get a 500 error. At least under Linux.

How come?

phpbugs@mattholland.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 12:01:31 2024 UTC