In A4D_PreStreamExecuteHook I basically grab the header part of the request from the receive buffer then put it back. I then examine the header text and determine what to do. Two lines:
$err:=ITK_TCPRcv ($streamRef;$headerTxt;32000;0;0;<>CRLF+<>CRLF;2*60) `Grab the header... $err:=ITK_TCPUnRcv ($streamRef;$headerTxt;1) `... and put it back!
With this code in place if I try to post from ~20000 to 32000 characters of text into a textarea on a form I've identified to be problemattic (back the 400 Bad Request problem) I get either 400 Bad Request or form variables collection corruption.
Since my test form is an Active4D page I can bypass A4D_PreStreamExecuteHook for testing purposes. If I comment out all my code and simply have A4D_PreStreamExecuteHook return true, I can successfully post the form with the large text fields no problem. Problem is for our production system I need to examine the request in advance.
My guess is that my attempt to examine the request and put it back is corrupting the request, but only in certain circumstances (same code has been in production for over 18 months).
So... Are there any other ITK Shell users or ITK gurus that do something similar in A4D_PreStreamExecuteHook. If so, can you comment on my code or share what you do?
Through a lot of trial and error I'll report that changing:
$err:=ITK_TCPRcv ($streamRef;$headerTxt;32000;0;0;<>CRLF+<>CRLF;2*60) `Grab the header...
to
$err:=ITK_TCPRcv ($streamRef;$headerTxt;1024;0;0;<>CRLF+<>CRLF;2*60) `Grab the header...
appears to have a positive affect. Using a smaller number for the 3rd parameter (maxLen) appears to solve my problem. That said, I have absolutely no idea why. I can also say that using a larger number not equal to but approaching 32000 causes problems. However, from my observations, I don't believe there is fixed number where things go wrong, and the number that "breaks it" is dependent on the content of the request.
FWIW, I had used 32000 as a conservative measure not knowing how large incoming request headers might be. Therefore, this "fix" does have the potential to break in the future.
-- Brad
_______________________________________________ Active4D-dev mailing list [email protected] http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
