StarDestroyer.Net BBS

I have a perl cgi program that goes to a directory and counts the number of lines in a file and returns a plain text page with that number.

The file is being written to by a c program (with the output fflushed after each write), and so is getting longer over time; the cgi is a progress checker that is polling the file to see how far along it is. The cgi has no idea how long the file "should" be in the end.

When called from internet explorer the cgi immediately returns the page saying how many lines there are. This is exactly as desired.

The problem is that when called from chrome the cgi waits until the file is complete, and then returns the number, thus totally defeating the point of a progress checker.

Debugging indicates that something impossible like chrome calling the cgi multiple times automatically is not happening.

Does anyone have any idea how and why the exact same program executed on the same computer can behave differently when told to run by different browsers?

Well I've got to the end of this with the help of some tech people. Just in case, as I absolutely hate to look something up and see someone with the same issue as me where their question went unanswered, or worse they just say "don't worry I solved it" I'm posting the solution here:

Solution (and same problem) described here:

http://www.perlmonks.org/?node_id=714883

key thing is:

perlmonks wrote: In my experience, you also need to close STDERR in the child (at least with recent Apaches), not only STDOUT.

Try adding

...
} elsif (defined $pid) { # child does
close STDOUT; # so parent can go on
close STDERR; # <--- THIS
...
[download]
(The open STDERR, ">&=1"; which you find in merlyn's code doesn't implicitly close file descriptor number 2 (stderr) under the hood ... as you can verify using strace. )

The fact that it (seemingly) works with Safari probably has to do with different browser buffering behavior, i.e. it presumably processes partial content differently (before the HTTP request has completed). But that's just a guess — at the moment I don't have a Safari to investigate this further. (You could check whether the individual Apache children (CGI processes) actually do terminate as expected in this case...)