Re: cgiirc problems

> > > Matus UHLAR - fantomas <[email protected]> writes:
> > > > They are the data from one POST request. Seems that wwwoffle buffers them
> > > > somehow and doesn't send them imediately to the client.

> Matus UHLAR - fantomas <[email protected]> writes:
> > This is what seems not to be completely true. I've noticed the same
> > behaviour yesterday, with different application (albums at
> > http://digi.perseus.sk/) - without wwwoffle pictures load smoother.
> > 
> > There may be some buffering at input or ourput at wwwoffle or socket level,
> > which causes delays. Could you please check it?

On 18.05.06 19:08, Andrew M. Bishop wrote:
> I don't know what version of WWWOFFLE you are using, but there are two
> possible sources of buffering.
> 
> If you have enabled chunked encoding from WWWOFFLE to the client (the
> reply-chunked-data=yes in the Options section) then there is some
> buffering.  The minimum buffering is 1 kBytes, if the data packet is
> bigger than this then it gets sent with no buffering, smaller packets
> are grouped together.  This is because the action of using chunked
> encoding adds extra information to the data stream.  If small blocks
> of data are sent on their own then more data needs to be sent in
> total.  You can try turning this option off and see if it helps.  The
> compression option (reply-compressed-data) will also add buffering,
> but I don't know how much, it is determined by the compressor (zlib),
> not by me.

Yes, that's it!
when I turned off reply-chunked-data, the page worked as expected.
I have reply-compressed-data turned off (I run wwwoffle on local machine).
However this way I will have to turned that off for all sites, since this is
global option.

Do you see any possibility to have the option reply-compressed-data per-site
configurable?

> 
> In version 2.9 there is extra buffering but only for data from
> WWWOFFLE to the client where it passed through the HTML or GIF
> modification functions or it is an internal message.  This extra
> buffering is to speed up the data flow, not slow it down.  (The data
> source will be making lots of small writes to the socket without this
> buffering, adding the buffering speeds things up, I tested it when I
> added it.)
> 
> 
> > > > The request lasted for a few minutes - until I clicked at "exit" button in
> > > > the generated page.
> > > 
> > > I don't understand what you mean by this.  Did you see any other
> > > WWWOFFLE requests during this time?  Did you expect any other requests
> > > during this time?
> 
> > no other requests, only one at all. IT seems to me that the gateway works as
> > one long-standing POST request which receives data and sends them in
> > parallel.
> 
> This is not the way that POST requests work.  They work like all other
> HTTP requests:
> 
> 1) client connects to server
> 2) client sends request to server
> 3) server reads all data
> 4) server sends reply to client
> 5) client reads all data
> 6) client and server close connection
> 
> It is possible for step 6 to be omitted and to go back to step 2, but
> this would be another request using the same socket, not more data in
> the same request.  The way WWWOFFLE works though is that it sends the
> correct headers to the client and server to tell them that the
> connection will be closed and reopened each time.  If the client or
> the server try re-using the same socket then they are not working
> correctly.
> 
> -- 
> Andrew.
> ----------------------------------------------------------------------
> Andrew M. Bishop                             amb-Uxr6IM1mbv2TY6FTCsQk+9Bc4/[email protected]
>                                       http://www.gedanken.demon.co.uk/
> 
> WWWOFFLE users page:
>         http://www.gedanken.demon.co.uk/wwwoffle/version-2.9/user.html

-- 
Matus UHLAR - fantomas, [email protected] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.