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

As for removing chunked encoding. Why is it actually needed???

The only reason I see is when you make a HTTP/1.0 request (no chunked support) and the browser a subsequent HTTP/1.1 request and the server returns a chunked response back.
I would think that it might be to ensure the client can always understand the request. Also it takes less time to make a subsequent request to a proxy than to the web server (most of the time).
Also as Carl indicated this requires the buffer of the proxy to be of infinite length if the connection must be kept open and this would even dramatically downgrade response time.

I think you shouldn't do this over HTTP/1.1 connections, and over HTTP/1.0 connections just by sending NO content-length...



About MSIE sending only two requests at a time: Microsoft has documented this and it is possibility to have the lowest response times for the web page. If one requests takes a lot of time, to the requests after this, the server will respond later. As a browser you cannot know the size of a request.
There was once a discussion about HOL (Head-of-Line) blocking that went into this problem. Microsoft avoided the problem this way...

- Joris


> -----Original Message-----
> From: Carl Kugler/Boulder/IBM [mailto:kugler@us.ibm.com]
> Sent: Thursday, 02 November 2000 20:46
> To: James Lacey
> Cc: http-wg
> Subject: 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 Sunday, 5 November 2000 09:17:13 UTC