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

Carl Kugler/Boulder/IBM wrote:

> >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

I didn't say that it wasn't a controversial requirement ...

>
>
> >>
> >>
> >>      -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:54:21 UTC