SPUG: CGI.pm issue

[Peter Darley]

Jeff,

	I can't say what the byte count was.  It was less than two pages of text,
so definitely less than 10K, probably less than 2K, maby as little as 1K.
Next time I'm in the office I can change my test server back and find out
for sure.

	Here's most of the info you asked for:

/proc/version:
Linux version 2.4.20-8 (bhcompile at stripples.devel.redhat.com) (gcc version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:18:24 EST 2003

rpm -qi http:
Name        : httpd                        Relocations: (not relocateable)
Version     : 2.0.40                            Vendor: Red Hat, Inc.
Release     : 21                            Build Date: Tue Feb 25 02:07:14
2003
Install Date: Tue Oct 14 05:15:20 2003      Build Host:
daffy.perf.redhat.com
Group       : System Environment/Daemons    Source RPM:
httpd-2.0.40-21.src.rpm
Size        : 2493055                          License: Apache Software
License
Signature   : DSA/SHA1, Tue Feb 25 07:05:56 2003, Key ID 219180cddb42a60e
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server

	I'm not sure how to check filters.  The lines in /etc/httpd/conf/httpd.conf
that talk about filters are:

AddOutputFilter INCLUDES .shtml

<IfModule mod_negotiation.c>
<IfModule mod_include.c>
    <Directory "/var/www/error">
        AllowOverride None
        Options IncludesNoExec
        AddOutputFilter Includes html

	I also don't know how to check for MPM.  Let me know how to check it and I
will.

Thanks,
Peter Darley

-----Original Message-----
From: spug-list-bounces at pm.org [mailto:spug-list-bounces at pm.org]On
Behalf Of Jeff Almeida
Sent: Friday, January 14, 2005 8:30 AM
To: Peter Darley
Cc: SPUG
Subject: Re: SPUG: CGI.pm issue


Peter,

This may very-well be related to the way that Apache is passing the data.
In particular, I'm curious as to the following:

* Which version of Apache you're running?
* On what OS?
* If it's a 2.0-flavored Apache, with which MPM?
* If it's a 2.0-flavored Apache, are you running any filters?
* What kind of byte count in the textarea was causing the cutoff?

jeff :)

Also Sprach Peter Darley:
>Charles,
>
>	Thanks for replying!
>
>	So, to rephrase this, the OS (or Apache or something) isn't passing the
>data fast enough for the entire block to get there in time for one read to
>catch it all, and doing the read repetitively gives it time to catch up.
If
>this isn't what you're saying, let me know. :)
>
>	Is your concern on the longer term outage that if a client drops during a
>post my loop will just continue forever?  If that's not it, could you
>elaborate on what the danger might come from?
>
>Thanks,
>Peter Darley
>
>-----Original Message-----
>From: DeRykus, Charles E [mailto:charles.e.derykus at boeing.com]
>Sent: Thursday, January 13, 2005 10:21 AM
>To: Peter Darley; SPUG
>Subject: RE: SPUG: CGI.pm issue
>
>
>I'm actually surprised that this was implemented with 'read'
>rather than the lower level, faster sysread. It must have been
>deemed adequate though since textarea usually don't try to
>pass for the kitchen sink :)
>
>Your revision sidesteps a potential OS 'gulp delay' for a ton
>of data by looping. However, a longer term outage might still
>occur and be problematic so I'd recommend an alarm and short
>term timeout mechanism to avoid blocking forever if you really
>need huge gulps.
>
>--
>Charles DeRykus
>
>
>-----Original Message-----
>From: Peter Darley [mailto:pdarley at kinesis-cem.com]
>Sent: Thursday, January 13, 2005 7:30 AM
>To: SPUG
>Subject: SPUG: CGI.pm issue
>
>
>Folks,
>	I had a problem with CGI.pm, that I was able to resolve, but now I'm just
>trying to understand exactly what the problem was.
>
>	The problem was that when I had a textarea form field that had a lot of
>data in it, the end of the data would be cut off.  I tracked this down to
>the read_from_client sub, which is only called once, so has to return all
>the data from the post in one go.  It wasn't returning all the data
however.
>
>	The original sub looks like this:
>
># Read data from a file handle
>sub read_from_client {
>    my($self, $fh, $buff, $len, $offset) = @_;
>    local $^W=0;                # prevent a warning
>    return undef unless defined($fh);
>    return read($fh, $$buff, $len, $offset);
>}
>
>	I checked $len and it always matched the ammount of data that was
expected,
>and offset was always 0, but it wouldn't read all the data in one go.  I
>couldn't find anything that indicated that read had an upper limit on what
>it would grab in one go.  Is there a limit like this?
>
>	The new sub looks like this:
>
># Read data from a file handle
>sub read_from_client {
>    my($self, $fh, $buff, $len, $offset) = @_;
>    local $^W=0;                # prevent a warning
>    return undef unless defined($fh);
>#    return read($fh, $$buff, $len, $offset);
>
>    while (read($fh, $Result, $len, $offset))
>    {
>        $$buff .= $Result;
>    }
>
>    return 0;
>}
>
>	Which works fine.  Basically I'm just reading till I run out of data and
>then returning 0 which is what read should return when it hits an EOF.
>
>	Anyway, I'm not sure what was causing the origional problem, so I'm not
>entirely sure that this is a totally safe change.  I have done a lot of
>testing and it seems to behave correctly.
>
>	Any revelation about what's going on here is appreciated.
>
>Thanks,
>Peter Darley
>
>_____________________________________________________________
>Seattle Perl Users Group Mailing List
>     POST TO: spug-list at pm.org
>SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
>    MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med
>    WEB PAGE: http://seattleperl.org/
>
>_____________________________________________________________
>Seattle Perl Users Group Mailing List
>     POST TO: spug-list at pm.org
>SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
>    MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med
>    WEB PAGE: http://seattleperl.org/

--
****************************************************************************
**
"Modern technology is already in use that makes electronic voting possible,
 with accurate and almost immediate tabulation and with paper ballot
printouts
 so all voters can have confidence in the integrity of the
process." -J.Carter
****************************************************************************
**
Jeff D. "Spud (Zeppelin)" Almeida                              Corinth, TX,
US
_____________________________________________________________
Seattle Perl Users Group Mailing List
     POST TO: spug-list at pm.org
SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
    MEETINGS: 3rd Tuesdays, Location: Amazon.com Pac-Med
    WEB PAGE: http://seattleperl.org/