Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am running a nph-script.cgi on my server.

The server keeps adding

HTTP/1.1 200 OK Date: Thu, 05 Nov 2009 02:28:53 GMT Server: Apache/2.2.8 (Ubuntu) PHP/5.2.8-1hardy~ppa1 with Suhosin-Patch mod_perl/2.0.3 Perl/v5.8.8 Content-Length: 0 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/plain X-Pad: avoid browser bug

At the bottom of each page loaded via the .cgi script. why is this the case? How do I remove this annoying message that is appended to all pages ?

share|improve this question

3 Answers 3

Are you sure that the server is setup correctly? Considering that the message claims that the content type is text/plain instead of text/html or something else, I'm thinking that something is wrong with how you setup CGI or your .cgi script.

share|improve this answer

This is an issue I've seen occasionally on our own WAMP server as well as LAMP hosting environments. The later releases of Apache 1.3 and 2.0 seemed to limit the issue, but it's regularly a problem with 2.2.

The issue is pronounced mainly when NPH scripts are combined with a rewrite. The issue is further compounded if you handle your own gzip compression, which is pretty much a requirement when using NPH scrips. If you aren't using URL rewriting, the issue pretty much disappears.

This is NOT documented anywhere, and I've had to determine the possible causes and solutions on my own. I've been able to (MOSTLY) resolve the issue in the following way: Adding a Content-Length header. This will ONLY work if you accumulate the page output prior to sending to the client, so that you can calculate the byte size for the header.

For example, as you build up your page, if you use Perl you would accumulate them into a variable such as $HTML and then when you've handled all the page processing, you would send that to a subroutine which handles the final output. What I also do is accumulate headers separately into a variable as needed prior to the final output and that effectively saves me the hassle of handling the output more than once, which helps a lot with debugging.

Here's a code snippet without gzip output support:

sub finish {
    my ($STATUS, $HEADER, $TYPE, $HTML, $ISNPH) = @_;
    my $HTTP_PROTOCOL = $ENV{'SERVER_PROTOCOL'}
    	if ($ENV{'SERVER_PROTOCOL'}
    		&& $ENV{'SERVER_PROTOCOL'} =~ m/^HTTP\/\d\.\d\$/);
    $HTTP_PROTOCOL ||= 'HTTP/1.1';
    $STATUS ||= 200;
    $TYPE ||= 'text/html';
    if ($STATUS =~ m/^30[123]$/) {
    	$HEADER .= "Content-Length: 0\n";
    	print "$HTTP_PROTOCOL $STATUS\n";
    	print $HEADER;
    	print "Content-type: $TYPE\n";
    	print "Location: $HTML\n\n";
    	exit;
    }
    print "$HTTP_PROTOCOL $STATUS\n" if ($ISNPH);
    print $HEADER;
    print "Content-type: $TYPE\n";
    print 'Content-Length: ' . length($HTML) . "\n" if ($ISNPH);
    print "\n";
    print $HTML;
    exit;
}

It would be called like this:

&finish('200', $HEADER, 'text/html', $HTML, 1);

If you're testing your script before making it support NPH, just pass a 0 as the last parameter. Simply don't print to the client at all prior to this function call and build up your headers into $HEADER and HTML into $HTML.

If you're doing a redirect, pass the URL you're redirecting to in the $HTML parameter. There's no need for actual HTML output in a redirect scenario.

To further resolve issues if you still see them, test your script with output buffering on & off.

There are still situations where this may not resolve the issue, and I've yet to pinpoint a solution, it should be brought up to the Apache Group. I only know CGI programming so I wouldn't have the capacity to research Apache source or submit patches, but hopefully someone takes this up.

~Jay

share|improve this answer

We are seeing a similar issue with an nph-file that acts as gateway to Intersystems Caché (a database and web application server). Works fine as long as we don't use URL rewriting. Any request handled by URL rewriting produces the spurious header described above (at or near the bottom of the response content).

We tried to isolate the bug with a small Perl nph-script and had the same problem. Tested on different servers: Apache/2.2.11 on Ubuntu 9.04, Apache/2.2.9 on Debian 5.0 and Apache/2.0.52 on Red Hat EL 4.

Script nph-test.cgi in regular cgi-bin directory:

#!/usr/bin/perl -wT
use strict;
print "$ENV{SERVER_PROTOCOL} 200 OK\n";
print "Server: $ENV{SERVER_SOFTWARE}\n";
print "Content-Type: text/plain\n\n";

# Tell Perl not to buffer our output
$| = 1;

print "OK.";

URL Rewriting

RewriteEngine On
RewriteRule ^test/([0-9]+)$ /cgi-bin/nph-test.cgi

(in Apache .conf file, under Directory /var/www/)

Response

OK.
HTTP/1.1 200 OK
Date: Mon, 07 Dec 2009 09:44:40 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain

Other sources describing the same or similar problems:

Using Content-Length works for the test-script, but doesn't solve our problem since we obviously can't change the nph-cgi executable that comes with Intersystems Caché.

As you say, this should probably be submitted to Apache, but the rules laid out at httpd.apache.org/bug_report.html are rather daunting. (I have limited knowledge of Apache.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.