Message-ID: <35602BA6.13B4@databeam.com>
Date: Mon, 18 May 1998 08:37:58 -0400
From: Rich Bowen <rbowen@DataBeam.com>
Reply-To: rbowen@DataBeam.com
Organization: DataBeam Corporation
MIME-Version: 1.0
To: rse@hyperreal.org
CC: apache-bugdb@apache.org, rse@apache.org
Subject: Re: general/2235: Apache 1.2.6 loses POST data
References: <19980518115728.1810.qmail@hyperreal.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: apache-bugdb-owner@apache.org
Precedence: bulk

> I've checked this with 1.3b7-dev and have a few
> comments:
> 
> 1. I was unable to verify the error. I tested 50 POSTs
>    with NS 4.0 and every one worked correctly

Again, we have repeatedly verified that this problem does occur.  And,
as I said, this happened on 1.2.6

> 2. I'm sure your given test program never run this
>    way for you, because
>    - under FreeBSD /usr/bin/perl is a Perl 4
>      which doesn't support neither "use" nor
>      "use strict", etc.
>    - the usage of "read" is totally wrong: read
>      returns the number of read characters and
>      not the buffer (the buffer is already given
>      as an argument).

This seems a rather strange thing to say, for a number of reasons.
First, it did indeed happen this way.
Secondly, on our BSD system, we do not have Perl 4 installed, but have
Perl 5 installed.  /use/bin/perl is a symbolic link to
/use/local/bin/perl, which is Perl 5.004_04, as I mentioned very
specifically in my report.  Perl 5.004_04 does support use, and use
strict.  
Third, the usage of "read" is exactly what I use to read in FORM data in
every CGI application on my system, and, additionally, is the syntax
used in "Programming Perl" by Larry Wall.  I would think that Larry
would know how to use the language that he invented.

I've been writing CGI programs almost as long as the CGI has existed,
and I find it a little disturbing that you are so quick to blame this
problem on my CGI code, particularly on such a basic stripped-down CGI
program of 5 lines.
 
> So, I conclude that the error you observe is
> either because of a programming problem inside
> your real program or caused by some other things
> we cannot reproduce with the current amount of
> information.

OK.  I am glad that you feel that this problem has gone away in version
1.3.  However, since we are not willing to put beta software on
production, mission critical machines, we were forced to retrograde to
1.2.4 on that machine, and we will wait for a released version 1.3.  I
am a little nervous about problems that just "go away" by themselves, as
they have a nasty tendency to resurface.  We have a suspicion that this
problem has to do with a server under load, rather than just a server
that is being used for test purposes, and suspect that the problem is
only likely to show up when there are several simultaneous requests
going on on the server.  We have been working with Apache since the NCSA
days, and feel that it is extremely unlikely that we just imagined this
problem.  As I mentioned in my problem report, we reproduced this
problem on a wide variety of browsers, and with a minimal CGI program in
order to eliminate possible dependencies on things outside of our
control, and are confident that the problem must rest on the HTTP
server, rather than on some other part of the equation.
-- 
##################################################
#  Rich Bowen                                    #
#  Web Services Engineer - DataBeam Corporation  #
#  rbowen@databeam.com                           #
##################################################