Can you send a short script (removing all the irrelevant bits) that we can reproduce the problem with?
Made a script that generated the same POST request and same redirect as the problem code. The problem was not reproduced!
The only difference I can see between working POSTs (both those in my package code and the one in the test script) and the failing one (a particular one in my package) is in the distribution of the data across the TCP packets that carry the POST.
Packet 1 always has the POST request and a set of headers.
When it works (a 302 is sent), Packet 2 has the Content-Type header, Packet 3 has the Content-Length header, and Packet 4 has the POSTed variables:
PACKET 2:
0x0000 4500 0065 f659 4000 4006 4993 9084 ecce [EMAIL PROTECTED]@.I.....
0x0010 9084 ecce 9ea1 0050 482e 99c3 4828 27ae .......PH...H('.
0x0020 8018 7fff cd14 0000 0101 080a 00a9 6185 ..............a.
0x0030 00a9 6185 436f 6e74 656e 742d 5479 7065 ..a.Content-Type
0x0040 3a20 6170 706c 6963 6174 696f 6e2f 782d :.application/x-
0x0050 7777 772d 666f 726d 2d75 726c 656e 636f www-form-urlenco
0x0060 6465 640d 0a ded..PACKET 3:
0x0000 4500 004b f65a 4000 4006 49ac 9084 ecce [EMAIL PROTECTED]@.I.....
0x0010 9084 ecce 9ea1 0050 482e 99f4 4828 27ae .......PH...H('.
0x0020 8018 7fff d88d 0000 0101 080a 00a9 6185 ..............a.
0x0030 00a9 6185 436f 6e74 656e 742d 4c65 6e67 ..a.Content-Leng
0x0040 7468 3a20 3334 320d 0a0d 0a th:.342....PACKET 4:
0x0000 4500 018a f65b 4000 4006 486c 9084 ecce [EMAIL PROTECTED]@.Hl....
0x0010 9084 ecce 9ea1 0050 482e 9a0b 4828 27ae .......PH...H('.
0x0020 8018 7fff 945c 0000 0101 080a 00a9 6185 .....\........a.
0x0030 00a9 6185 5f70 6173 735f 6964 3d75 7365 ..a._pass_id=use
0x0040 7233 2534 306d 616b 6574 6865 6361 7365 r3%40makethecase
0x0050 2e6e 6574 265f 7061 7373 5f70 6173 733d .net&_pass_pass=
[rest of packet cut]
But when it fails (a 200 with a 302 link is sent), all is in the one packet:
0x0000 4500 01af 1d11 4000 4006 2192 9084 ecce [EMAIL PROTECTED]@.!..... 0x0010 9084 ecce 9faf 0050 f769 cb03 f764 9ec7 .......P.i...d.. 0x0020 8018 bb9e fe65 0000 0101 080a 00ad a4b7 .....e.......... 0x0030 00ad a4b7 436f 6e74 656e 742d 5479 7065 ....Content-Type 0x0040 3a20 6170 706c 6963 6174 696f 6e2f 782d :.application/x- 0x0050 7777 772d 666f 726d 2d75 726c 656e 636f www-form-urlenco 0x0060 6465 640d 0a43 6f6e 7465 6e74 2d4c 656e ded..Content-Len 0x0070 6774 683a 2033 3037 0d0a 0d0a 5f70 6173 gth:.307...._pas 0x0080 735f 6964 3d75 7365 7233 2534 306d 616b s_id=user3%40mak 0x0090 6574 6865 6361 7365 2e6e 6574 265f 7061 ethecase.net&_pa 0x00a0 7373 5f70 6173 733d ss_pass= [rest of packet cut]
Could mod_perl, with its persistent buffer, be tripping up on this? I'm trying now to trace the data through the mp2 code. -- Mark
