lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev "hanging" after d)ownloading large file


From: Vlad Harchev
Subject: Re: lynx-dev "hanging" after d)ownloading large file
Date: Sat, 18 Dec 1999 00:17:24 +0400 (SAMT)

On Sat, 18 Dec 1999, Klaus Weide wrote:

> On Fri, 17 Dec 1999, Vlad Harchev wrote:
> 
> >  I see this too, but only if using lynx for DOS, connecting via
> > WinProxy3.0, while getting files as a result of link activation ( I didn't
> > test plain downloading yet). 
> 
> > I have extended read progress status enabled, and 
> > for some sites lynx "handgs" when getting the page (as a result of normal 
> > link 
> > activation) - the read status shown is like 
> >     Read 2345 of 2345
> > - ie all content is read, 
> 
> No it doesn't mean that.  Not reliably, not for HTTP.

 At least downloaded page seems complete.

> > but seems that remote server didn't close
> > connection. As I remember, all http servers with which I saw this problem 
> > was
> > Apaches. Seems that this problem is not caused by Proxy - there is a status
> > window for WinProxy, that shows all present connections - with 'hanging' 
> > lynx
> > connection among them
> 
> I don't see how this leads to the conclusion that it's not the proxy's fault.

 I assume that http server should close connection (by doing close(2) on
socket), not client or proxy (if user doesn't terminate transfer). 
Since proxy code that handles connection is probably simple (so it less
likely to contain bugs), and proxy has not noticed the fact that socket was 
closed (if it noticed, a line from the status window would have been removed),
I conclude that Windows TCP stack is broken. I used Win95 with very
old TCP stack implementation (WinProxy suggested me to upgrade my TCP stack
during installation with a newer one - and suggested me URL, but I didn't).
Another point - seems WinProxy is bug-less (I hope) - seems they sell a lot
of copies to be reach to fix bugs.

> > (so I assume that either remote server or Windows TCP
> > stack is guilty).
> 
> 
>    Klaus
> 

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]