Andrew M. Bishop
Thu, 18 May 2006 22:25:00 -0700
Matus UHLAR - fantomas <[EMAIL PROTECTED]> writes: > > > On 25.02.06 21:02, Andrew M. Bishop wrote: > > > > I don't know how this particular web page works, but it is not > > > > possible for a server to push data out to the browser, only the > > > > browser can request it from the server. If you have set the options > > > > so that WWWOFFLE is not caching the page then it should work as well > > > > with WWWOFFLE as without it. > > > 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. > > On 12.04.06 19:27, Andrew M. Bishop wrote: > > WWWOFFLE will read all of the POST request from the client (browser) > > and then send all of it to the server. The data comes back from the > > server and is sent straight to the client. WWWOFFLE does not hold on > > to the data for longer than it needs to. > > 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? 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. 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 [EMAIL PROTECTED] http://www.gedanken.demon.co.uk/ WWWOFFLE users page: http://www.gedanken.demon.co.uk/wwwoffle/version-2.9/user.html