Re: Fundamental architecture of a proxy implementing keep-alive.

"James A. Donald" wrote:
>
> I have been trying to write a proxy based on the example provided by
> junkbuster, because it was relatively short and intelligible, and compiled
> on my target system (NT) and then I found that the basic architecture of
> junkbuster seems incompatible with the entire Keep-Alive concept.
>
> Junkbuster relies on the connection NOT being kept alive in order to tell
> where one request ends and another begins, and fails to translate and act
> upon
> - Keep-Alive
> - Connection
> - Proxy-Authenticate
> - Proxy-Authorization
> - TE
> - Trailers
> - Transfer-Encoding
> - Upgrade
>
> Instead it mindlessly passes them along, producing all sorts of nasty
> failures.
>
> The first problem with keep-alive is that I do not know how to tell where a
> request or response ends, so that do not know when I can throw away state
> for the previous request and prepare to translate new state.
>
> RFC 2616 section 4.3 and 4.4 seems to tell me how I can find the end of a
> client request or server response, but it is a large complicated scary
> prescription, and it is often far from clear to me what they are saying and
> what they mean.

The answer is Content-length. Unless you are doing chunked encoding. So
if you drop transfer-encoding support and anything else that relies on
chunked encoding then your job gets a whole lot simpler. If the response
has a Content-length header, then your object is exactly that long, or
ends when the connection does, whichever happens first. If you don't
have a content-length, then the object ends when the connection does,
and that's that.

Anytime you cannot predict the length of an object in advance, you
should break persistance.

Squid doesn't handle the chunked (aka interleaved) encoding, so life is
a lot simpler for it than RFC2616 implies.

D
Received on Wed Aug 25 1999 - 00:52:37 MDT