--MimeMultipartBoundary
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
carson@tla.org wrote:
> Actually, perhaps we should call getsockopt(...SO_ERROR...) to
> find out what the status of the connection is...
Won't help. The receiving TCP can't see any difference between a
shutdown() or a close() until a write or keep-alive packed is issued.
I whish there was a way to push a keep-alive check, but I don't know of
any..
Maybe we should selectively enable keep-alive for the few browsers that
use it? I don't know of any current browser that uses shutdown(), but
have a vague memory that there once in a time was a few versions of a
browser from IBM that used it. I think this browser was later changed to
use normal closes..
As I have said before, I think that using shutdown() in a client is a
violation against HTTP. RFC 2068, section 8.1.4:
When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
respond to it as appropriate. If a client or server does not detect
the other side's close promptly it could cause unnecessary resource
drain on the network.
This, combined with the fact that there is only one close operation in
TCP (FIN =3D=3DI have no more data to send) indicates that shutdown() is
not legal to use when more data is expected, except where it is
important that previously send but un-acknowledged data is received
properly (=3D=3Dby a server/proxy).
The same section also says:
Servers SHOULD NOT close a connection in the middle of transmitting
a response, unless a network or client failure is suspected.
The question is: Is a TCP FIN on a active connection a sign of client
failure or not?
If client shutdown() is allowed while waiting for a response then there
is no way to detect aborts on stalled connections until either a
keep-alive check or timeout.
--- Henrik Nordstr=F6m Sparetime Squid Hacker --MimeMultipartBoundary--Received on Tue Jul 29 2003 - 13:15:47 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:45 MST