It's twue, it's really twue. (Lily VonShtup)

The sample script was stripped to the absolute bare essentials. Since I was trying to fix a problem in *gag* authenticate.cgi */gag* and the customer did not want to pay for a total rewrite I started cutting down to the fundamental issue. The fundamental issue being: when a pdf file was feed back to a browser it worked fine with Netscape 4.7 or less and with MSIE 5 or less. But a pdf file feed back to a browser would not work with Netscape 6 and MSIE 5.5

So I eliminated all subroutines, password monkey business, logging mumbo-jumbo, and everything else getting down to spitting out a pdf file based on a script just being called.

"Please kick me. I must be missing something here?!?"

No need. I kicked myself enough running around in circles trying to figure out what these new versions of Netscape were upto.

Turns out just the Submit button was enough data in the stream to cause a problem.

Near as I can tell when these new versions of Netscape and MSIE send a POST they go into a "waiting for a request to send data" mode.

If anything other than a "request to read waiting data" comes back to the browser these new versions seem to eat the first string, figure out that the server is not going to ask for data, then start sending the rest of the incoming bytes to the "render the darn page" subroutines.

I do believe the first string sent to a new browser after a POST is being dumped. Maybe out of spite for being left hanging around with perfectly good posted data. Maybe because the error recovery from an apparently broken CGI session is not the greatest. The older versions of the browsers managed to send the string on into the rendering subroutines. The newer versions don't seem to do that. Leastwise that is the apparent effect.

The solution to this is to either use the GET method or: read(STDIN, $forminfo, $content_length, $offset);

The offending script was using <STDIN> to snarf up the POST data. Apparently there is something happening in the newer browsers such that <STDIN> is not "doing the whole trick" -- at least not in this one form/script combination.

If I replace the read with <STDIN> the script won't fully function for Netscape 6. And if I put the read() back in the script works fine. Or alternately I can switch the POST method to a GET method.

I'm sure this isn't the whole story. But with the exception of a zillion and a half Matt's scripts still in use around the internet anyone using CGI.pm (which utilizes a proper read($fh, $$buff, $len, $offset);) should be fine.

So while rewriting the script from scratch would have solved the problem by incorporating proper use of CGI.pm, I do think there is some value in understanding some of the nuances of what's happening in the innards.

Claude