keepalives again

Hi all,
as I see we can divide and conquer w.r.t. keep-alive.
The divison can be done by separating the connection-dependent (persistent
http related) stuff from unrelated client-server states.
For the first half, we have the max and timeout question.
The MAC/TCP problem mentioned by Beth Frank reopens the question (for me),
but not knowing the details we can't go forward.
-- 3 days later: according to Roy's suggestion: what is the real difference
between the TCP abort and TCP close on MAC?
The problem seems not being http specific. How this problem is solved in other 
TCP/IP based protocols/applications? Discussing this with MAC developers may 
help. Who knows the MAC guys?
For the second half of the problematics (the state/context ascpects) we have
different domain. Contexts/states can be keept indepently from TCP connections.
(Authentication contexts are a special case, however they can be keept using a 
more complex technique. Persistent TCP connections help here a lot, but still
don't solve the problem completely.)
The Accept-signature concept originally wasn't tied to persistent connections.
In the accept sense there are 3 contexts for a browser:
1. web page
2. inline (character based apps like lynx never use this context.)
3. download (Accept */*)
We should implement some feature, enabling easy switch between these contexts.
The other context type is the authentication context. Proxies, multiplexing
many clients to a server somehow should be able to change this context too.
To discuss this, we should consider first the proxy authentication problem.
(how the authentication done by the proxy can be propagated?)
And there may some other contexts to exist. Which other contexts should be
supported in 1.1? 
Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Wednesday, 25 October 1995 13:54:05 UTC