Stas Bekman wrote:
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.
[snippet the packet dumps]
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
mod_perl 2.0 is buffering only the content (response body, not the headers) (assuming that you aren't installing any output filters), so it's one of the apache core output filters, that decides how to split the data.
a normal output filter list ends with:
byterange(0x8841110): ctx=0x0, r=0x88402d0, c=0x883a390 content_length(0x8841128): ctx=0x0, r=0x88402d0, c=0x883a390 http_header(0x8841140): ctx=0x0, r=0x88402d0, c=0x883a390 core(0x883a760): ctx=0x883a738, r=0x0, c=0x883a390
you can dump this, using the dump_filters macro, which you can load by running
gdb> source /path/to/httpd-2.0/.gdbinit
the 'core' filter is in httpd-2.0/src/core.c: core_output_filter(...)
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
