Recently, Gary Dietz of Whitman College posted a message about his site's
experience with a "buffer overflow" problem with both the OMI webserver
and the NCSA webserver on the HP3000. A simple statement of the problem
is this: A "large" HTML page sent to the user from the webserver is often
incomplete; it is missing some quantity of bytes and is unusable.
Because both products appeared to have the same problem, Gary implied
the real problem may lie elsewhere (MPE internals? POSIX interface?) and
noted that an SR had been opened with HP. SRN has duplicated the problem
on small HP3000s (S/918 and S/928) under 5.0 and 5.5 MPE/iX.
As many of you know, SRN has a Web product for the HP3000 called IRISLink,
and our clients -- some with NCSA and some with OMI -- have reported the
same problems when dealing with "large" HTML pages generated by our CGI
programs. Their HP3000's range from small, resource-starved systems to
large, resource-rich systems. The problem occurs with all of the popular
browsers. There does not seem to be a problem with pages under 16Kb in
size. Larger than that, results are unpredictable.
The purpose of this posting is to again ask the assembled body for help
in isolating and identifying the problem. Since so few of us are noting
the problem, it may be that most sites simply don't have the problem
because they are configured differently, and that our problem is one of
incorrect installation of (or version of) one or more parts of MPE or
its subsystems. On the other hand, maybe we are configured fine and
only a few of us are reporting it. From our tests, it would appear that
EVERYONE with an HP3000 webserver should have the problem, and if that is
true then HP CSY should be concerned.
This is a good place to skip to the next message if you are not interested
in the problem, and my apologies for the use of bandwidth. Read on if
you want to read what we observed in our testing.
First we tested to make sure that our CGI programs were doing the right
thing. We found out that the CGIs are definitely writing back the complete
page to the HTTPD server, but that the server either does not receive the
complete page or it does not transmit the complete page back to the browser.
We conducted this test on both the OMI and NCSA servers and results came
out the same.
We looked in the access and error log files to see what was reported.
The error log gave no indication of any problem. The access log did
tell us that regardless of the actual size of the HTML page, 32,768 bytes
were returned in most cases and that at other times we are only getting
back 16,384 bytes. The first value is 2^15 and the second value is 2^14,
exactly half. These figures are very suspect.
Once in a blue moon we would get back the complete page, which was just
over 50Kb. With a problem like this we had to have a workaround, since
many of the most useful IRISLink reports exceeded 32Kb.
The workaround that we have come up with for now is to have the CGI programs
pause for about .03 seconds after each write back to the HTTPD server.
This has greatly increased the probability that we get the full page back
in our browser, but we still get incomplete pages sometimes. We tested
with a variety of "delay intervals" and it seems that increasing the
pause time increases the probability of getting a complete page.
Of course, the longer the pause the longer it takes the CGI to return
the entire page, and the user's perception of the usability of the
product is negatively impacted.
Any ideas out there? Respond to me directly or post to the list as you
think best. If I get a private reply that constitutes a miraculous cure,
I will post it.
========================================================================
Raymond Deans 206-463-3030 (Voice)
Software Research Northwest, Inc. 206-463-9393 (FAX)
[log in to unmask] 206-463-3555 (BBS)
"Here's good health to your enemies' enemies"
========================================================================
|
