Read from StnIn from POST is still broken?
Mark Waddingham
36degrees at runrev.com
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.
------------------------------------------------------------------
Mark Waddingham ~ 36degrees at runrev.com ~ http://www.runrev.com
Runtime Revolution ~ User-Centric Development Tools
More information about the use-livecode
mailing list