Miernik <[EMAIL PROTECTED]> writes:

> I notices that wwwoffle doesn't send any response to browser until
> completely fetched the page. 
> 
> That has some udesirable cosequences:
> 
> For example I have set in my bowser a receive timeout of 120 s. 
> I send a Pragma: no-cache request for a very large page to refetch a
> new version from source. WWWOFFLE starts fetching this page, and does so
> for 120 seconds, but is not yet finished then. But the browser doesn't
> know anything about that - it thinks that something went wrong and our
> requset got lost. So after 120 seconds it issues another Pragma:
> no-cache request, than WWWOFFLE rejects the half-way fetched page and
> starts over from the beginning. And so on... 
> 
> This way it will never fetch this page. 
> 
> Solution to set a larger timeour in browser is some sort of solution, eg
> I have set 600 s now, but then if the request realy got lost, it would
> not do anything about it for 10 minutes. 

If the browser timeout is much bigger than the WWWOFFLE timeout then
you should not have a problem because WWWOFFLE will tell you as soon
as its timeout has expired.

> I know that is because I have
> 
> enable-modify-online           = yes 
> 
> but maybe we could make WWWOFFLE send something to the browser even then,
> because this way it is sometimes unusble. 

The problem is that there is nothing sensible that WWWOFFLE can send
to the browser until the page is loaded and the modifications made.

WWWOFFLE can't send the header because we don't know how long the file
is going to be after we have modified it.  For the same reason we
can't send the data.

The only solutions that I can think of are not to send the length in
the header, but that would not then be HTTP/1.1 compliant.  The other
option is to use the chunked transfer encoding, but that only works
with HTTP/1.1 browsers and adding support for that into WWWOFFLE would
be a large task.  It would mean for example that WWWOFFLE would need
to work differently if the browser does support it or not.  It is not
as simple as supporting compression from WWWOFFLE to the browser.

-- 
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop                             [EMAIL PROTECTED]
                                      http://www.gedanken.demon.co.uk/

WWWOFFLE users page:
        http://www.gedanken.demon.co.uk/wwwoffle/version-2.7/user.html

Reply via email to