Re:x2 Reading RAW POST data

[grinder]

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

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';

[IlyaM]

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/)

[IlyaM]

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/)