W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 2000

Re: Of HTTP/1.1 persistent connections and TCP Keepalive timers

From: Fred Bohle <fbohle@neonsys.com>
Date: Thu, 2 Nov 2000 12:27:24 -0600
To: CN=Carl_Kugler/OU=Boulder/O=IBM_ <kugler@us.ibm.com>
cc: James Lacey <James.Lacey@Motorola.com>, http-wg <http-wg@hplb.hpl.hp.com>
Message-ID: <8625698B.00666642.00@internet1.neonsys.com>




Fred Bohle@NEON
11/02/2000 12:27 PM


     We seem to be diverging into TCP coding.  A read will return zero
length
when the other end has issued a normal close (and all the data has been
read).
A read will return -1 when the connection is ReSeT, or there is a
connection time-out
of any sort.  So the server can too tell the difference between end of data
and
a connection failure.

Fred




From: Carl Kugler/Boulder/IBM <kugler@us.ibm.com> on 11/02/2000 11:59 AM

To:   James Lacey <James.Lacey@Motorola.com>
cc:   http-wg <http-wg@hplb.hpl.hp.com>

Subject:  Re: Of HTTP/1.1 persistent connections and TCP Keepalive timers


...
>
>For example, suppose the  server sends back an HTTP response to the client
>that does not have a Content-Length: header field and that it is not
>chunked.
>
>Then the only way the client knows that it has read the
>entire response off of the pipe is when the server closes the connection.
>When the server closes the connection the client will receive a
>zero-byte read which is socket layer's indication that the pipe
>is broken.
>
This is not good.  If this is the server's normal behavior, the client has
no way to distinguish a dropped connection from end of file.  So the client
can never be sure it received an entire message.

If this is the server's behavior for error conditions, this is still not
good unless the server either waits for the entire request (could be a
humongous POST and/or a very slow connection), or only closes one half of
the connection (which, BTW, is impossible in Java, except maybe in the
latest releases).  Otherwise, the client might get a RST while transmitting
the request, and will then never see the error response.

...
>
>I've done some snoops on browsers that are GETting HTML pages with
>lots of embedded links that are in the same realm as the original HTML
>page.
>
>Despite this obvious opportunity to take advantage of persistent
connections
>the browser opens  a connection for each subsequent GET.
>
I was looking at IE's (version 5 somthing) traffic yesterday, and it seems
to send two requests per connection.


     -Carl
Received on Thursday, 2 November 2000 18:38:04 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:40 EDT