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

>Sent by: jlacey@mothost.mot.com
>Carl Kugler/Boulder/IBM wrote:
>
>> I stand corrected.  But then, why was Content-Length added in HTTP/1.0
and
>> Tranfer-Encoding: chunked in HTTP/1.1?
>
>Content-Length was added so that persistent connections would be possible.
>
>Without a content length, neither the client or the server would know
>where the message ended. You have to realize that TCP is a stream and
>it is up to the users of the stream to impose some kind of framing
protocol
>onto the stream.
>
>Transfer-Encoding: chunked was added so that servers could return
>possibly large dynamic content in chunks, as it was generated, so that
>the server did not have to buffer up all of the dynamic content before
>sending it back. With chunking you can also have persistent connections
>w/o the need of a Content-Length header field.
>
Ah yes, make perfect sense now.

>One curious think about chunking that I do not understand is that
>HTTP proxies are required to move the chunked (any?) encoding before
>forwarding the response.
>
That's news to me.  Doesn't that apply only to MIME gateways or something?
Wouldn't that require a potentially infinite buffer in the proxy?  Wouldn't
it have a horrible impact on response time?

     -Carl

>>
>>
>>      -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 Thursday, 2 November 2000 11:49:23 UTC