in reply to How do I read POST data that is not encoded, and was submitted without a parameter name

A simple way to read raw POST data is the following code excerpt 
sub _read_content {
    my ($self) = @_;
 
    my $length = $ENV{CONTENT_LENGTH};
    my $buf;
 
    read STDIN, $buf, $length;
 
    return $buf;
}

[download]
I use it to read in a XMLRPC request which I process with Frontier::RPC2. But you can use it to read in any XML POST data ( no multipart forms ... ) and do some processing on it.
Johan

Replies are listed 'Best First'.
Re: Reading RAW POST data
by IlyaM (Parson) on Dec 15, 2001 at 05:21 UTC
    AFAIK read only tries to read specified amount of data from filehandle and actually can return less data. Correct code should use loop like: 
    
sub _read_content {
    my $length = $ENV{CONTENT_LENGTH};
    my $rest = $length;
    my $buf;

    while($rest < $length) {
        my $read = read STDIN, $buf, $length - $rest, $rest;
        die "Can't read from a stream: $!"
            unless defined $read;
        return $buf if $read == 0;
        $rest += $read;
    }

    return $buf;
}

    [download]

    --
    Ilya Martynov (http://martynov.org/)

[reply]
[d/l]

      In the general case, this code would be very fragile. Servers can lie about content length; things can go wrong. You should attempt to try to read a certain number of times, possibly giving up after a series of consective reads that draw zero bytes, and/or return all that you have after a given amount of time.

      update to Ilya's response: I should clarify my statement. Several years ago I had that sort of code running in a script, and I came to grief over the problem of content length. It didn't always correspond to what I received. I no longer have access to the code, so I can't go and look it up, but in a nutshell I ignored the content-length value, and just tried to read as much as I could in a certain time frame (45 seconds IIRC).

      That said, I'm willing to believe that servers these days are much more reliable, and produce accurate values for content length... although I think I'll always mistrust them.

      --
      g r i n d e r
      just another bofh

      print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u';
[reply]
        Reply to updated node:

        I would not completely ignore content-length. It can be incorrect sometimes (user agents can lie) but it is useful as upper limit for input data (and I use it as such in my code). I'm not sure but AFAIK under mod_perl you never get 'end of file' from STDIN. So even if content length is correct your code punishes good user agents with 45 seconds delay.

        --
        Ilya Martynov (http://martynov.org/)

[reply]
        Why do you think this code is fragile? It handles both unexpected end of stream (by checking if read returns zero bytes) and it handles errors (by checking if read returns undef). Timeouts should be handled by web server so unless you have some special requirements you should not care about read time.

        --
        Ilya Martynov (http://martynov.org/)

[reply]

In Section Seekers of Perl Wisdom