Read from StnIn from POST is still broken?
psahores at easynet.fr
Sat Mar 4 04:39:05 EST 2006
I did'nt have the opportunity to test this for a while but what works
100% fine (we went spoken about before if i right remember) is to
stick a PHP sockets listener in front of your Rev CGI script or Rev
backgrounder stack based app. A very reliable way to do Rev able to
support very heavy write-mode transactions traffic. After height
years in using this design, i never had a socket brokken in only one
of my running production's apps. At this time, i just know that 800
connections/second is the top-stressed level one of my apps has
sometime to support and, in this situation, all worked always as
expected without any "accident" (Athlon XP Pro 800, 1Go RAM, Suse-
Linux from september 2000 to september 20005 - Mac OS X 10.3.9, 1Go
Ram, G4 box since september 2005).
See as a reminder of the second way to go, the "paper" and
downloadable example app at <http://istream.homeunix.com/insead/
index_en.html>, my little xDSL test and home mac mini server.
Le 4 mars 06 à 03:48, Sivakatirswami a écrit :
> This is a really old problem: Rev CGI scripts are truncating data
> piped from Apache from a POST....
> Does anyone know for "positively absolutely" sure that new version
> of rev has over come this issue?
> Linux web server, Apache, call Rev CGI to receive incoming Post
> Data. Beginning lines of script to read the incoming data -- see
> below (suggested as a possible fix years ago by Scott Raney)
> (musings... it is possible that this is a client side problem?
> --machine A with browser B cannot in fact encode large chunks of
> data and the name=value pair actually arrive to the server already
> truncated.. meanwhile
> -- box C with browser D submits a large text chunk from the same
> form and it arrive just fine: result Rev get blamed for being
> intermittent failures... but he's really not the bad guy.
> on startup
> if $REQUEST_METHOD is "POST" then
> put "" into PostIn
> repeat until length(PostIn) >= $CONTENT_LENGTH
> read from stdin until ""
> put it after PostIn
> end repeat
> put urlDecode (PostIn) into tDataIn
> split tDataIn by "&" and "="
> put keys(tDataIn) into tFields
> if one of the incoming name pairs contains too much data, it is
> You can stress test this yourself: go to:
> and scroll down to the end of the list...the last "story is a
> submission with a large text chunk pasted into the main field.
> The full cgi is here:
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode