[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: lynx timeline
From: |
Leonid Pauzner |
Subject: |
Re: lynx-dev Re: lynx timeline |
Date: |
Mon, 9 Jun 2003 13:03:31 +0400 (MSD) |
8-Jun-2003 12:26 Ilya Zakharevich wrote:
> On Thu, Jun 05, 2003 at 01:42:37PM -0700, I wrote:
>> Sorry, what I meant was the "header-part" of the document, one
>> finished by the first "\r\n\r\n" (if I got this correct).
>>
>> When we receive the header, it should be a good indication
>> that the server is going to deliver the document - at least
>> not worse than it did the last time ;-).
> Leonid asked: And what if we got "500 Server error" responce, supplied
> with a nice "please contact a webmaster" page? What about non http://
> schemes? Any other ideas?
> I think the discussion of error=500 is hair-splitting now: one needs
> to run the new purging scheme for some time, *then* one can decide
> which action is more appropriate. [On the other hand, one can just
> delegate the choice to the user via a .cfg setting.]
I guess Ilya Zakharevich want a workaround for the following configuration:
lynx runs on a standalone PC, without local proxy, with dial-up connection.
When dial-up went down and you try to revisit some link - you got a message
"could not connect to remote host" (or like) and the old copy of the
document _removed_ from the HText cache. The "no_cache" an "Expired" items
are also relevant here.
This is very different from the case when you talk to the proxy and
the proxy reply with "connection timed out" informational page;
or you receive a partial document and the transfer stalls.
I am more agree with Bela: we may need several copies of the document
(HText + HTParentAnchor), each with timestamp and status, and the ability to
select between them according to some rules (interactively and/or via .cfg).
> One can deal with any scheme the following way: when the first byte of
> *content* (as opposed to headers/envelop) is recieved, the old version
> is purged. So if no headers are defined for a scheme, the purge
> should happen on the first successful read()/recv().
> Thanks,
> Ilya
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
- Re: lynx-dev lynx timeline, (continued)
- Re: lynx-dev lynx timeline, Leonid Pauzner, 2003/06/04
- Re: lynx-dev lynx timeline, Leonid Pauzner, 2003/06/04
- lynx-dev Re: lynx timeline, Ilya Zakharevich, 2003/06/04
- lynx-dev Re: lynx timeline, Ilya Zakharevich, 2003/06/04
- Re: lynx-dev Re: lynx timeline, Leonid Pauzner, 2003/06/05
- lynx-dev Re: lynx timeline, Ilya Zakharevich, 2003/06/05
- Re: lynx-dev Re: lynx timeline, Thomas Dickey, 2003/06/05
- Re: lynx-dev Re: lynx timeline, Leonid Pauzner, 2003/06/06
- lynx-dev Re: lynx timeline, Ilya Zakharevich, 2003/06/08
- Re: lynx-dev Re: lynx timeline, Bela Lubkin, 2003/06/08
- Re: lynx-dev Re: lynx timeline,
Leonid Pauzner <=
- lynx-dev Re: lynx timeline, Ilya Zakharevich, 2003/06/10
- Re: lynx-dev Re: lynx timeline, Leonid Pauzner, 2003/06/10
- lynx-dev Re: lynx timeline, Ilya Zakharevich, 2003/06/10
Re: lynx-dev Re: lynx timeline, Leonid Pauzner, 2003/06/05
Re: lynx-dev lynx timeline, Henry Nelson, 2003/06/03