Re: lynx-dev partial display (was: on caching)

[Klaus Weide]

On Wed, 18 Nov 1998, Leonid Pauzner wrote:
[KW:]
> > But if a client sends a request line with "HTTP/1.1", then the servers
> > is entitled to assume that the client
> >  - wants persistent connections (unless "Connection: close" is sent)
> 
> One problem in partial display mode remind me this.
> while accesing certain rare sites with lynx
> I got repainting the screen on _previous_ document, not the downloading one,
> so I analize the trace and add a semaphore against HText_new().

I don't understand why you think it could have something to do with
something at the HTTP protocol level.  Lynx doesn't do persistent 
HTTP connections anyway.  :)

Maybe it has something to do with how the response we receive is packaged
into packets.  Often servers ship off the data in such a way that
the message headers are in one network packet, and then it is likely that
the first call to HTCopy() from HTLoadHTTP() starts with the first
bytes of the message body (because the first read() from the network
socket has delivered just the headers).  The call

  /*
  **  Recycle the first chunk of data, in all cases.
  */
  (*target->isa->put_block)(target, start_of_data, length);

before the HTCopy() in HTTP.c will have shipped just the headers to
the MIME parser.  So when HTDisplayPartial() gets first called from
HTCopy(), there will already have been a block of body data shipped
to the SGML and HTML parsers.  Then it is likely that the new HText
structure has been created at that point.

If on the other hand not all message headers fit in one network packet
(or datagram, to be more exact), or if for some other reason the read()
in HTLoadHTTP() hasn't yet read all header data, then the first call
to HTCopy() may still be passing just header fields to the MIME parser,
so that when HTDisplayPartial() is first called, no part of the body
has been seen and a new HText structure has not yet been created.

Does this make sense?


    Klaus