Dirk Lutzebaeck <[EMAIL PROTECTED]> writes:
> Chip Turner writes:
> > You can always use the definitive test of tcpdump on the client
> > machine. Something like (on linux):
> >
> > /usr/sbin/tcpdump -s 4096 -w packets.out src (host) and port 80
> >
> > Then examine packets.out for what data is returned in which packets.
> > With a large enough sleep in the modperl code, it should come pretty
> > much in its own packet. This will pretty much give you complete
> > certainty on what the client receives and when the client receives it.
>
> Ok, I'll check this. Umm, I forget to say that I'm using mod_ssl, ie. it is an
> SSL-request. Maybe it buffers something?
Well, SSL eliminates the usefulness of tcpdump :) Yes, it very well
may buffer data, as it uses a block cypher (be it 3DES, IDEA,
Blowfish, etc), which typically operates on four to eight bytes at a
time. The SSL layer may indeed be buffering above the Apache/mod_perl
level. Can you test it on a non-SSL connection? The dump may still
give you info that _A_ packet was received, just not the contents in
it. Putting several print/fush/sleep combos with varying delays may
show you if it is in fact sending the data.
Chip
--
Chip Turner [EMAIL PROTECTED]
ZFx, Inc. www.zfx.com
PGP key available at wwwkeys.us.pgp.net
