I think that I may have isolated our problems to some code I have in A4D_PreStreamExecuteHook.

Our ITK Shell has been modified (since day one) to check for Active4D pages requests and CGI type requests. The CGI Type requests allowed us to serve a bunch of old Netlink code (in 4D methods) we had with ITK. Most, but not all, of that code has been ported to Active4D, but one large web application remains to be rewritten.

Active4D requests are handled off to Active4D and the CGI type requests to another method. A code snippet from A4D_ITK_Slave looks like this:

 If (A4D_PreStreamExecuteHook ($streamRef))
   A4D_ITK_Server ($streamRef)  `Handle the incoming HTTP request(s)
 Else
   a4d_ITK_DoCGI ($streamRef)
 End if

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?

I have inquired with the plug-in author and the U.S. vendor regarding this matter. No response yet.

Thanks,

Brad Perkins
_______________________________________________
Active4D-dev mailing list
[email protected]
http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev
Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/

Reply via email to