Welcome to WebmasterWorld Guest from 54.226.2.31

Forum Moderators: DixonJones & mademetop

Message Too Old, No Replies

nph scripts show no xfer length in logfiles?

apache config question

     

Bolotomus

4:11 am on Jul 13, 2001 (gmt 0)

5+ Year Member



A question regarding using nph script on apache. The platform is:
Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a

I made this nph script and put it in my cgi-bin directory. I gave it the clever name of 'nph-script'

#! /usr/bin/perl -w
use strict;
print "HTTP/1.1 200 OK\n";
print "Content-Type: text/plain\n\n";
print "1234567";

I do the necessary chmod's and call it up on my browser through the web; it works fine. But then I look in the logfiles and see

198.137.240.91 - - [12/Jul/2001:23:59:02 -0400] "GET /cgi-bin/nph-script HTTP/1.1" 200 -

What's that "-" doing where the transfer length is supposed to be? So think, aha! My nph script doesn't give a proper content-length. So I fix it like this:

#! /usr/bin/perl -w
use strict;
print "HTTP/1.1 200 OK\n";
print "Content-Length: 7\n"; # set content-length
print "Content-Type: text/plain\n\n";
print "1234567";

Good idea, but that doesn't fix it. Just to make sure I'm not going batty, I rename the script to "not-an-nph-script", rem off the "print HTTP/1.1" line, and voila, I get the correct logfile entry:

198.137.240.91 - - [13/Jul/2001:00:02:40 -0400] "GET /cgi-bin/not-an-nph-script HTTP/1.1" 200 7

What's up? Is this some bug that I should know about logging nph-scripts on Apache?

Bolotomus

littleman

6:45 am on Jul 13, 2001 (gmt 0)

WebmasterWorld Senior Member littleman is a WebmasterWorld Top Contributor of All Time 10+ Year Member



I think it is because a nph script keeps apache from generating termination strings, which must act as a byte rate marker.

Bolotomus

3:33 pm on Jul 14, 2001 (gmt 0)

5+ Year Member



What's a "termination string"? Can I just print one myself from my own nph-script?

littleman

2:46 am on Jul 17, 2001 (gmt 0)

WebmasterWorld Senior Member littleman is a WebmasterWorld Top Contributor of All Time 10+ Year Member



You know, I tried to find some documentation on this. I couldn't find anything, but this is my theory:
When you use an nph script the script is responsible for it's own buffering. So I was thinking that the buffering mechanism is tied to apache's ability to recored transfer size. I read somewhere that if you use an nph script and you turn buffering off ($¦=1) then the actual transfer size will be greater than the size the script will produce. So that all sort of fits together. If anyone knows about this please jump in.

Bolotomus

5:43 am on Jul 17, 2001 (gmt 0)

5+ Year Member



Ah yes, $ ... thanks for that idea. I went and did some tinkering, trying various combinations of using IO::Handle to do automatic output flushing, and to set $=1

No luck. Your comment that the nph-script shows a length bigger than the actual output (presumably in the logfiles) makes sense to me--of course, apache would consider the header of an NPH script as part of the output whereas normally it wouldn't. BUT in my case I cannot get the logfiles to show any length for nph-scripts, ever. Maybe I should try this experiment on a few other servers... perhaps its something about the particular release of Apache I'm using, or something...

One thing I've learned. If I ever use somebody's system where I'm paying by the BYTE for execution of cgi scripts, I'm gonna make *everything* an nph script... :)

Bolotomus

Brett_Tabke

7:50 pm on Jul 17, 2001 (gmt 0)

WebmasterWorld Administrator brett_tabke is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



No, you are right on the money here Bolotomus. I am running 50% nph's here and I don't get xfer length either.

Like little said, it is Apache's inability to count the output and record it. Apache uses the same routine to report content length to the browser. Apache Can NOT know what the header length is going to be and turns off the content length counter on nphs's (has too). It's a known issue and it will require more code overhead for them to address - so they've skipped it. There was a message last fall (couldn't find it via google) in comp info servers about this issue.

 

Featured Threads

Hot Threads This Week

Hot Threads This Month