Read from StnIn from POST is still broken?

Mark Waddingham 36degrees at
Mon Mar 6 05:17:16 EST 2006

Hi Sivakatirswami,

> 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
> .....etc.

There is no reason I can see (engine-side) as to why post data should  
get truncated. That being said, however, you should ensure that you  
pass '-ui' to the revolution engine when running as a CGI.

(i.e. the first line of a cgi script should be:
   #! /<path to rev cgi>/revolution -ui

[ The -ui option alters a few things internally, in particular  
disables attempts to create any GUIs and enables stdin/stdout on  
systems - such as Win32 - which don't by default have these enabled ]

I actually had a similar issue many many moons ago when we were  
automating our order processing. At the time I fixed it by writing a  
small shell wrapper that did the following:
   1) write the input out to a temporary file
   2) run revolution with file as a parameter
   3) delete the temporary file

Although this system interfaces with postfix rather than a CGI - and  
in this case the resulting problem was as much to do with concurrency  
as anything else. However, if you want a copy of the wrapper script  
email me off-list and I'll dig it out for you.

Whether there is an underlying problem or not is difficult to say as  
we are talking about several interacting systems. If large form data  
gets truncated when submitted from all browsers all the time, then  
there is definitely something up. If, however, it does not happen all  
the time then perhaps looking for the browser type might help track  
down the issue - as would trying to discern whether it is always  
truncated to the same length.

Hope this helps,


  Mark Waddingham ~ 36degrees at ~
        Runtime Revolution ~ User-Centric Development Tools

More information about the Use-livecode mailing list