SPUG: CGI.pm issue

Peter Darley pdarley at kinesis-cem.com
Thu Jan 13 10:30:42 PST 2005


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/



More information about the spug-list mailing list