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

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

transfer encodings (of which chunk is one) are hop to hop.. so they
have to be theoretically removed.. but if the outgoing encoding is the
same as the incoming encoding that phsyical operation can certainly be
optimized away. The requirement is that the outgoing encoding meets
the requirements of the request received by the proxy.. so if the
proxy gets a 1.0 request it will need to remove 'chunked' and
terminate the message in some other fashion. 

That other way is probably to buffer it and add a CL, or more likely
terminate it by closing the connection.

which leads me to a pet peeve of mine.. 2616 prohibits the sending of
CL when a non identity transfer encoding is used.. consider the case I
just used of a 1.1 proxy with a 1.1 origin-server and a 1.0
user-agent.. the proxy receives a 1.1 chunked (and something else non
identity) response but it's only choice to send it downstream is to
buffer it in a store and fowrard fashion to figure out the content
length or close the connection w/ EOF which would rob of it of the
chance to use 1.0 style keepalives... 

admittedly some folks think 1.0 keepalives ought to be burned.. but by
that argument all responses to 1.0 reqs should lack CL's and be TCP
terminated, right?

if the content length is known by the original sender it seems a
little odd to lose this information if for no reason other than use in
resource allocation or UI thermometer widgets. Certainly with dynamic
content the server probably doesn't know the CL anyhow at header time,
but what if it's just sending say trasnfer-encoding: deflate, chunked
??

-P

Received on Thursday, 2 November 2000 12:22:30 UTC