Brad Perkins wrote:
Brad Perkins wrote:
More info on this. These problems coincided with the release of a new structure. Changes in that structure were solely for desktop client users. Nothing changed in my A4D ITK Shell code. Anyway there was other "weirdness" with this release and we ended up downgrading to the previous version yesterday.Aparajita Fishman wrote:
Also, a few months back you published some changes to A4D_ITK_ReceiveCallback on this list. We weren't having any problems then and didn't install that. Might that help here?
Yes, it might definitely help, as that problem had to do with large uploads. You can find the fixed code in the mailing list archives.
Thanks. If it doesn't help back to capture the full request plus headers. Would I do that in my 4D code or with an external utility?
Actually there was one notable difference. A month or so I was trying to isolate why our development web client was hanging during startup and upgraded to a later beta version of ITK 2.6.1. We had been running version 2.6.1b1 and tried to run 2.6.1b4. FWIW, the 2.6.2 version that is on the ITK web site is unusable.
I'm curious, for those of you that are running ITK for your web server on MacOS X, what version do you have running in production? What version of MacOS X?
Still working on this issue. Here's some more information and a lot of questions.
Previous suggestion to capture the full request and write to file shows that the requests appear to be intact before being handed off to A4D. This effectively rules out my theory that a proxy server was causing problems. The full text fields are making it to A4D. Total request size is less than 32K.
I also did some reports on our database to capture max text field submission sizes for our database to see if the user that initially reported the problem had exceeded an untested limit. What I found was that while larger text submissions are common the system in question had on a number of occasions accepted requests larger than the one reported.
In looking at the issue tracker, I found issue 0000486: 400 Bad Request Error which has a status of resolved.
Is the resolution the shell changes to "A4D_ITK_ReceiveCallback". I have the method below installed.
`METHOD: A4D_ITK_ReceiveCallback( ` inStream: Longint; ` inStopString: Str255; ` inMaxLen: Longint; ` inTimeout: Longint) -> BLOB
`Part of Active4D, the ultimate 4D web environment `Copyright � Aparajita Fishman, All Rights Reserved
`v4.0.0 build 2 2005-01-22 ` `30-Mar-2005, bdp, Installed into A4D 3.0 ITK Shell
C_LONGINT($1;$inStream;$3;$inMaxLen;$4;$inTimeout) C_STRING(255;$2;$inStopString) C_BLOB($0) $inStream:=$1 $inStopString:=$2 $inMaxLen:=$3 $inTimeout:=$4
C_LONGINT($result) C_BLOB($data) C_BOOLEAN($receivingHeader) $receivingHeader:=(Length($inStopString)>0)
While ($inMaxLen>0)
`Receive up to $inMaxLen bytes, don't release the stream when done, append to $da
$result:=ITK_TCPRecvBlob ($inStream;$data;$inMaxLen;0;3;$inStopString;$inTimeout)
Case of
: ($result<0)
SET BLOB SIZE($0;0)
LONGINT TO BLOB(0;$0;Macintosh byte ordering )
: ($result=0) | ($receivingHeader)
$inMaxLen:=0
Else
$inMaxLen:=$inMaxLen-$result
End case
End while
$0:=$data SET BLOB SIZE($data;0)
---------------------------------------------- Is this the right method? Is this code dependent on other shell changes that I probably don't have?
I'm not getting 400 errors, per se, but am seeing corruption in the form variables collection which I'll try to explain shortly.
In the issue tracker there is a note on 0000486: 400 Bad Request error in the Additional Information section which reads ' If you change the encoding type of the form to "multipart/form-data'. Was their more information there that might help? Does changing the encoding type have a positive or negative benefit?
Re: the form variables corruption I mentioned earlier...
In my testing I'm trying to submit ~20K of text into a form that has various fields, but a single "description" text field. The 20K text is some sample greeked "lorum ipsum" text. When I submit the form it comes back with my own error messages saying I'm missing form data. What is strange is that some of the fields that are missing are fields that I were definitely entered. To debug this I dumped the form variables collection and found that a number of variables on the form are getting clobbered. Dump Collection is showing me that I have a form variable with the key = "semper suscipit purus. In lorem ante, consectetuer eu, elementum id, mollis nonummy, eros. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam pharetra. Vivamus posuere velit porttitor tortor. In rutrum vestibulum nunc. Morbi laor" and a value = "baseline". Baseline would normally be the value of my "f_request_type" variable. The "f_request_type" and a number of other variables are no longer in the form values collection. Instead I've got an undefined form variable whose key appears to be text from part of the posted description. More on this below.
Another thing I notice is the the "f_description" field is in the form variables collection, but the value does indicate truncation based on the size displayed:
" Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Suspendisse pharetra, nibh ut bibendum aliquam, dui lorem ullamcorper orci, eu sodales arcu arcu in orci. Integer vel arcu. Sed ultrices lacinia turpis. Pellentesque luctus massa in felis. Ut eui..." [14906 chars]
On examining the position of the mysterious greeked form variables I find that the key text appears a few bytes after where "f_description" was truncated?
Doing some rough math I suspect that given 14906 chars and other form data that the total request size is being cut off at 16K? In Active4D.ini I did not have a default request size set, but Active4D.ini says the default is 64. I've since set it to 64 but that doesn't seem to help.
Since running the above test I've tried some other large tests with ever worse results. Instead of getting a form with missing data back I can repeatedly put the server in a non-serving state which means having to go the server and force quit 4D Client. I've tried to see what is going on with Client using the runtime explorer, but Client is apparently stuck in a loop somewhere because the "rainbow beachball" just spins and spins.
A4D 3.0 Mac OS 10.2.8 4D Client 6.8.4 (Win2K Server) WebSTAR 5.3.4 using Rewrite
I've stayed at 3.0 because it has worked well for us and our shell is modified (some of our old web apps haven't been rewritten to use A4D yet and use the classic ITK server approach which replaced Netlink). If going to a later beta will help here I'm willing to try that but only if it is known to fix this problem.
BTW, I'm continuously dumping my .res and .rex files. Datacheck gives the data file a clean bill of health. The structure checks out fine with 4D Tools and Sanitycheck.
-- Brad Perkins
_______________________________________________ Active4D-dev mailing list [email protected] http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
