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

Content-length in HTTP/1.0 is not directly needed, except when using the addional RFC purposing persistent connections. It gave the client a indication of the length of the file. This is nice when downloading a large file, you know that you have all the data received (in case of line failures)...

HTTP/1.1 added chunked encoding in order to let HTTP implementations benefit when sending content where the length is not known (like dynamic content or an real-time video/measurement) and benefit from the persistent connections. The next request (e.g. a picture) can be requested without waisting time to open a new connection.


That looks like the most logic explaination for me....

- Joris

> -----Original Message-----
> From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
> Sent: Thursday, 02 November 2000 20:07
> To: Fred Bohle
> Cc: James Lacey; http-wg
> Subject: Re: Of HTTP/1.1 persistent connections and TCP 
> Keepalive timers
> 
> 
> 
> I stand corrected.  But then, why was Content-Length added in 
> HTTP/1.0 and
> Tranfer-Encoding: chunked in HTTP/1.1?
> 
>      -Carl
> 
> 
> 
> "Fred Bohle" <fbohle@neonsys.com> on 11/02/2000 11:27:24 AM
> 
> To:   Carl Kugler/Boulder/IBM@IBMUS
> cc:   James Lacey <James.Lacey@Motorola.com>, http-wg
>       <http-wg@hplb.hpl.hp.com>
> Subject:  Re: Of HTTP/1.1 persistent connections and TCP 
> Keepalive timers
> 
> 
> 
> 
> 
> 
> 
> 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 Sunday, 5 November 2000 09:17:13 UTC