SPUG: CGI.pm issue

[Jeff Almeida]

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