Server closing socket without notice

I am seeing SilverStream servers closing HTTP/1.1 connections immediately
after a small random number of GET requests without notice - no 'connection:
close' response header is returned with the last successful request.

Is this behaviour consistent with
a) the spirit of the RFC
b) the letter of the RFC

I understand that servers will close idle connections after some time, but
in this case a FIN packet arrives typically within 0.5 seconds of the last
successful request, which may be before or after the client has sent the
next request.  The client is not pipelining requests - it waits for a
response to each request before submitting the next - but does not expect
the behaviour described above.  The servers in question are not stressed.

If this behaviour is normal, can you confirm the natural corollary to this -
that any HTTP/1.1 client must cope with a 'null' response to any 2nd or
subsequent HTTP/1.1 request by creating a new socket and re-submitting the
request - even where no 'connection: close' response header was included
with the previous response?

Thanks,
Matt Black