This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: can't get unbuffered output to work
From: Dirk Lutzebaeck <lutzeb@aeccom.com>
Date: Thu, 13 Jul 2000 17:17:45 +0200 (CEST)
Steve van der Burg writes:
> >Hi, unbuffered output in a handler just doesn't work for me:
> [ details of setup and handler snipped ]
> >
> >If I 'GET /unbuffered' in Netscape nothing is printed until I stop the
> >server. Setting $|++ does not help. Something is still buffering. This
> >is modperl 1.21 and Apache 1.3.12.
> >
> >Any clues?
>
> Netscape is waiting for an HTML visual break of some kind before showing any output - if you modify your test handler to spew "<b>Hello!</b><p>" before sleeping, you should see it.
No, sorry Steve, this doesn't help. I've also tried <BR> and
text/plain. MSIE is no different.
===
Subject: Re: can't get unbuffered output to work
From: "Eric Cholet" <cholet@logilune.com>
Date: Thu, 13 Jul 2000 18:12:23 +0200
Steve van der Burg writes:
> > >Hi, unbuffered output in a handler just doesn't work for me:
> > [ details of setup and handler snipped ]
> > >
> > >If I 'GET /unbuffered' in Netscape nothing is printed until I stop the
> > >server. Setting $|++ does not help. Something is still buffering. This
> > >is modperl 1.21 and Apache 1.3.12.
> > >
> > >Any clues?
> >
> > Netscape is waiting for an HTML visual break of some kind before showing any output - if you modify your test handler to spew
"<b>Hello!</b><p>" before sleeping, you should see it.
>
> No, sorry Steve, this doesn't help. I've also tried <BR> and
> text/plain. MSIE is no different.
I've noticed that MSIE doesn't start displaying stuff until it has a certain amount,
say a few hundred bytes. After that it displays just fine.
===
Subject: Re: can't get unbuffered output to work
From: Dirk Lutzebaeck <lutzeb@aeccom.com>
Date: Thu, 13 Jul 2000 18:24:59 +0200 (CEST)
Eric Cholet writes:
> > Steve van der Burg writes:
> > > >Hi, unbuffered output in a handler just doesn't work for me:
> > > [ details of setup and handler snipped ]
> > > >
> > > >If I 'GET /unbuffered' in Netscape nothing is printed until I stop the
> > > >server. Setting $|++ does not help. Something is still buffering. This
> > > >is modperl 1.21 and Apache 1.3.12.
> > > >
> > > >Any clues?
> > >
> > > Netscape is waiting for an HTML visual break of some kind before showing any output - if you modify your test handler to spew
> "<b>Hello!</b><p>" before sleeping, you should see it.
> >
> > No, sorry Steve, this doesn't help. I've also tried <BR> and
> > text/plain. MSIE is no different.
>
> I've noticed that MSIE doesn't start displaying stuff until it has a certain amount,
> say a few hundred bytes. After that it displays just fine.
No, doesn't seem to matter in my case. Is there any place I can verify
that Apache has sent some data to the client?
Dirk
===
Subject: Re: can't get unbuffered output to work
From: Chip Turner <chip@zfx.com>
Date: 13 Jul 2000 12:29:43 -0400
Dirk Lutzebaeck <lutzeb@aeccom.com> writes:
> > I've noticed that MSIE doesn't start displaying stuff until it has a certain amount,
> > say a few hundred bytes. After that it displays just fine.
>
> No, doesn't seem to matter in my case. Is there any place I can verify
> that Apache has sent some data to the client?
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.
Chip
===
Subject: Re: can't get unbuffered output to work
From: Dirk Lutzebaeck <lutzeb@aeccom.com>
Date: Thu, 13 Jul 2000 18:32:31 +0200 (CEST)
Chip Turner writes:
> Dirk Lutzebaeck <lutzeb@aeccom.com> writes:
>
> > > I've noticed that MSIE doesn't start displaying stuff until it has a certain amount,
> > > say a few hundred bytes. After that it displays just fine.
> >
> > No, doesn't seem to matter in my case. Is there any place I can verify
> > that Apache has sent some data to the client?
>
> 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?
Dirk
Subject: Re: can't get unbuffered output to work
From: Dirk Lutzebaeck <lutzeb@aeccom.com>
Date: Thu, 13 Jul 2000 18:32:31 +0200 (CEST)
Chip Turner writes:
> Dirk Lutzebaeck <lutzeb@aeccom.com> writes:
>
> > > I've noticed that MSIE doesn't start displaying stuff until it has a certain amount,
> > > say a few hundred bytes. After that it displays just fine.
> >
> > No, doesn't seem to matter in my case. Is there any place I can verify
> > that Apache has sent some data to the client?
>
> 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?
===
Subject: Re: can't get unbuffered output to work
From: Chip Turner <chip@zfx.com>
Date: 13 Jul 2000 12:36:44 -0400
Dirk Lutzebaeck <lutzeb@aeccom.com> 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
===
Subject: Re: can't get unbuffered output to work
From: darren chamberlain <darren@boston.com>
Date: Thu, 13 Jul 2000 13:15:10 -0400
Dirk Lutzebaeck (lutzeb@aeccom.com) said something to this effect:
> No, doesn't seem to matter in my case. Is there any place I can verify
> that Apache has sent some data to the client?
try:
$ telnet myhost 80
GET / HTTP/1.0
(two carriage returns)
You should see what the server is sending. For SSL, use port 443 instead of 80.
===
Subject: Re: can't get unbuffered output to work
From: Paul <ydbxmhc@yahoo.com>
Date: Thu, 13 Jul 2000 10:58:23 -0700 (PDT)
darren chamberlain <darren@boston.com> wrote:
> Dirk Lutzebaeck (lutzeb@aeccom.com) said something to this effect:
> > No, doesn't seem to matter in my case. Is there any place I can
> verify
> > that Apache has sent some data to the client?
>
> try:
>
> $ telnet myhost 80
> GET / HTTP/1.0
>
> (two carriage returns)
>
> You should see what the server is sending. For SSL, use port 443
> instead of 80.
Won't SSL confound a telnet connection to HTTPS on 443?
===
Subject: Re: can't get unbuffered output to work
From: James G Smith <JGSmith@TAMU.Edu>
Date: Thu, 13 Jul 2000 13:46:32 -0500
Paul <ydbxmhc@yahoo.com> wrote:
>
>--- darren chamberlain <darren@boston.com> wrote:
>> Dirk Lutzebaeck (lutzeb@aeccom.com) said something to this effect:
>> > No, doesn't seem to matter in my case. Is there any place I can
>> verify
>> > that Apache has sent some data to the client?
>>
>> try:
>>
>> $ telnet myhost 80
>> GET / HTTP/1.0
>>
>> (two carriage returns)
>>
>> You should see what the server is sending. For SSL, use port 443
>> instead of 80.
>
>Won't SSL confound a telnet connection to HTTPS on 443?
Not if you can type the SSL protocol :P
You might want to look at the s_client command in the OpenSSL suite (see
http://www.openssl.org/ for more information).
===
Subject: unbuffered proxying [was: can't get unbuffered output to work]
From: Dirk Lutzebaeck <lutzeb@aeccom.com>
Date: Thu, 13 Jul 2000 21:26:04 +0200 (CEST)
Folks, thanks for all your immediate help. I think the problem is
clear now: I'm using a typical proxy setup with
lightweight SSL-frontends and heavyweight mod_perl-backends. What I
would like is an unbuffered output from the backends across the
frontends but the proxy setup is _buffering_:
Internet <----> apache/mod_ssl frontends <-----> apache/mod_perl backends
[Port 443] [Port 81]
I'm using mod_rewrite for proxying in the frontend:
RewriteRule ^/(.*) http://my.internal.server:81/$1 [P]
What I need I guess is an unbuffered proxy setup in some situations,
ie. a flag to pass to mod_rewrite to push the buffer eg. until \n is
reached. I'm not into the nitty-gritty of all this stuff, maybe
someone has an idea or has already solved this.
===
Subject: RE: unbuffered proxying [was: can't get unbuffered output to work
From: Dirk Lutzebaeck <lutzeb@aeccom.com>
Date: Thu, 13 Jul 2000 21:51:23 +0200 (CEST)
Sheth, Niraj writes:
> I also had the same problem, but withouth ssl.
>
> i could think of two solution.
> 1. Modify front end apache's source code manually( i guess default is
> HUGE_STRING_LEN (8k)), but it sounds little scary ..
>
> so i opted for second choice ...
>
> 2.
>
> in your perl script ...
>
> print "something ...\n";
> my $lines = "\n" x 4096;
> print $lines; # now proxy server is happy at this point.
Yes, thanks I just tried it, it works! The only drawback is that I
have to send always 4k possibly over slow lines to get some timely
messages across...
===