On Wednesday, April 7, 2004, at 11:13 PM, Sannyasin Sivakatirswami
wrote:
This is probably something we need to carve into stone to save future
CGI users a lot of grief.
This is probably applicable to all kinds of stream I/O with limited
buffer space such as TCP protocols and even serial with
At 7:13 pm -1000 7/4/04, Sannyasin Sivakatirswami wrote:
Then we dug out an old note from Scott Raney on this subject of POST
failures where there was a lot of data being sent... but we had been
experiencing this even on very small data uploads... and the syntax in
the CGI he sent for the fix
Hi Katir,
I experimented this,a long time ago... At least with the 2.3.2 and
above issues of the engine, MC/Rev is failing 1 time peer 20 periods in
handling POST requests in CGI mode.
It's a sad reproductible bug we spoken about with Scott Raney, a long
time ago, on and off-list, without
Sannyasin,
This just a shot in the dark (and not a full solution), but is there
any chance you could pass your data to the server as part of a GET
request, or in a cookie header, instead of POST? That might get around
the Rev bug...
- Brian
___
At 3:01 pm +0200 8/4/04, Pierre Sahores wrote:
I experimented this,a long time ago... At least with the 2.3.2 and
above issues of the engine, MC/Rev is failing 1 time peer 20 periods in
handling POST requests in CGI mode.
It's a sad reproductible bug we spoken about with Scott Raney, a long
time
Hi Dave,
I did'nt test it for a while, now but, in about the POST method - i
don't never use the GET one, because its always possible security holes
-, at least, i got the problem in using the 2.5 engine too ;-( I had a
dedicated test stack, there, on one of my boxes. I will test again, as
Thanks, Pierre for the full report on this old bug... but the problem
with your solution is two fold:
1) it assumes that the Rev developer has PHP skills (which I do not)
even though we could simply copy your example... we would not know what
we were doing... and many new users of xTalk CGI
Hi Katir, Tuviah,
You are true. It would be great to have this core bug definitivelly
removed from the engine by the RunRev Team... True, again, that my
proposal is probably not feeting your needs if you don't own nor manage
the servers whose are hosting the PHP + Rev's application server
