cancel
Showing results for 
Search instead for 
Did you mean: 

Form stopped working after PHP upgrade. The script echoes to browser instead.

datascope
Newbie
Posts: 3
Registered: ‎15-09-2010

Form stopped working after PHP upgrade. The script echoes to browser instead.


Our Perl scripts stopped working!
We had a script, working earlier this year, which has recently (in the last few months) begun being echoed to the browser instead of executing.
(Aside - the form which called the script did not use an extension and indeed the script in CCGI space did not have an extension.  Maybe this is now needed?)
We believe the change happened with the server upgrades, which included the move from PHP4 to 5. However, the script in question appears to be written not in PHP, but in Perl. I had to find this out from its contents, since it had no extension.  I must stress that absolutely *nothing* in our files, or their naming, had changed when we first noticed this.
Details of what I've tried so far are to follow. Sorry if I've missed any useful, technical details of our particular setup, but I am personally fairly new to this system. We'll attempt to get back to you ASAP with any such details that are at all useful.
What I've tried so far:
Suspecting the difference in server setup and the lack of a file extension, I first tried adding an extension to the script. I tried .pl and .cgi -- and even .php since I was unable to convince my boss that it definitely wasn't PHP! With a file extension, the server seems to try executing the file, but immediately returns an error 500. Specifically, the error page includes the line:
Premature end of script headers: mailer.pl
, which of course suggested that there was something wrong with the script itself.
So I reduced the amount of code that runs... and reduced it some more... Very quickly, we were down to a single line! We have confirmed by phone that this line is the correct header for running Perl with Plusnet, and it reads:
#!/usr/bin/perl
The error message is unchanged in this case. It's still a 500 error, still reporting a 'premature end of script headers'. I've played extensively with file permissions, including foolishly liberal settings for my own test files, and this still does not alter anything.
At this stage I'm at a loss for what to test. The best clue we can find is in the FAQ at http://community.plus.net/library/settings/cgi-platform-php-upgrade-faq under question 8, where it says:
"8) I'm getting a server 500 error when trying to browse to my web site
"The most common reason for this error is where customers are using .htaccess directives that are not compatible with the new servers. The new platform allows .htaccess to override only: FileInfo, AuthConfig and Limit directive types. This is much more secure but may cause some formerly-allowed directives to fail e.g. IndexIgnore must be removed. For more information about this, please refer to the forum post here. If you're receiving this error then you should also check that your permissions adhere to the limitations detailed above."
there are many details alluded to here, but not given anywhere that I can find. What, for instance, are the details of the 'formerly-allowed directives'? It could be a promising lead, and I'd like to confirm or eliminate it.
Does anyone else have experience of this problem, and a potential solution that I haven't tried? The more the merrier! It seems to be a fairly generic error code, so any one answer might be necessary, but by itself insufficient.
Finally, I noticed on a question by gabe on 16/3/10 (about new ccgi permissions) that the problem ended up being solved by Ben Brown who looked at the filesystem and apparently "the home directory had the wrong group".  I am not sure what that means or even how it could have happened, because ours was working before the php upgrade and we therefore assume that the upgrade caused the problem.

Thanks in advance,
Julien
7 REPLIES 7
spraxyt
Resting Legend
Posts: 10,063
Thanks: 674
Fixes: 75
Registered: ‎06-04-2007

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

The perl script needs a .pl extension and its file permissions need to be 0700. Directories below the top level need to have permissions 0710 (or at most 0750 if the server has to read directory content (e.g. because it contains images)).
Do you have any .htaccess files? An incompatible option in one of these is a likely source of the server 500 and the premature end of script headers errors. Could you try with any .htaccess file disable?
David
datascope
Newbie
Posts: 3
Registered: ‎15-09-2010

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

Thanks for this.  I have added the .pl exension to the script file and changed the reference to it on the form.  There was a second script there as well (called from the first) and I have given this a .pl extension.
I have changed permissions to these two scripts to 0700 and changed the permissions to the CCGI  folder in which they sit (we called this folder cgi-bin) to 0710.  One thing I was not clear about was whether I ought to also change permissions to the ftp folders in which the html pages sit.  Initially I did change them but then I found I could not even open the website !  So I changed them back.  The odd thing is that when I try to go to the site (www.jobsocialnetwork.com) I get a popup asking me for password (private area - bad password).  So I must have made an error resetting the permissions.
We now get a 500 error
As for the .htaccess files - I don't think there are any.  How would I find out for sure?
Any further ideas please?
Best regs and thanks for taking the trouble so far.

Oldjim
Resting Legend
Posts: 38,460
Thanks: 787
Fixes: 63
Registered: ‎15-06-2007

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

Can you check your link as that IP address in the pdf gives this result
datascope
Newbie
Posts: 3
Registered: ‎15-09-2010

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

Everything sorted  :).
The popup was caused by wrong permissions so I simply reset them to allow all users and groups access (755, i think)
The more worrying problem of the 500 error was solved by replacing all instances  of 0D0A with 0A in the mailer and genmail scripts.  Apparently the new level of PHP whcih Plusnet upgraded to, is more sensitive to this.  I gather that if one uses a DOS editor to create/edit the script then instead of getting a line feed (0A) you actually get a CR plus line feed.
Plusnet ought to raise the profile of this problem because I am sure there will be othes witht his problem!!!
Thanks to those who helped.  I hope this helps others with the 500 problem.

oliverb
Grafter
Posts: 606
Registered: ‎02-08-2007

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

I notice that some things seemed to only run in the cgi-bin folder, not sure about the "why". Maybe if its group-readable the server sees it as text and echoes it instead. The cgi-bin folder seems to be locked down so a file won't get echoed no matter what you set permissions to.
I find the extensions behavior inconsistent, I had a shell script I wanted to run and I think I ended up renaming it something.cgi and putting it in cgi-bin before it would run. Presumably the first line determines how the script is interpreted in which case the extension should be redundant?
last time I looked php scripts didn't need to be in cgi-bin but perl scripts did?
spraxyt
Resting Legend
Posts: 10,063
Thanks: 674
Fixes: 75
Registered: ‎06-04-2007

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

On the old cgi server it was necessary for PHP files to be outside cgi-bin and perl files inside cgi-bin. On the new server those requirements no longer apply. Both types of files must have their respective .php or ,pl extensions.
Bash shell scripts can also go anywhere but do need the .cgi extension.
The way processes are forked on the new server requires that an appropriate file extension is specified even though the shebang line at the top of some scripts provides equivalent information.
David
oliverb
Grafter
Posts: 606
Registered: ‎02-08-2007

Re: Form stopped working after PHP upgrade. The script echoes to browser instead.

Quote from: spraxyt
On the old cgi server it was necessary for PHP files to be outside cgi-bin and perl files inside cgi-bin. On the new server those requirements no longer apply. Both types of files must have their respective .php or ,pl extensions.

Thanks, that wasn't quite the behavior I observed but I'll have another look. I may have got the permissions wrong as I tended to use "750" not "700" before