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

"James A. Donald" wrote:
> > 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.

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

What about objects that do not have bodies, for example most gets, and
the response to a HEAD request?

Will the following algorithm work?

        If there is no Content-Length or Transfer-Encoding, assume
        there is no body, and the message ends with the first blank
        line.

        If there is a Content-Length, assume the Content-Length bytes
        following the first blank line are the body.

        If there is a Transfer-Encoding, and no Content-Length,
        suppress the Connection: Keep-Alive header and ensure the
        presence of a "Connection: Close header". Assume that the end
        of the message will be indicated by a termination of the
        connection, and just pass everything as is until the
        connection terminates.

        Pass through the TE header

        Suppress the Ugrade header.

Will a client issue to a proxy two requests for two different
different servers on the same connection? If it does then the proxy
would have to do some nasty serialization code

If this never happens, then the following algorithm should work.

        When the client initiates a new connection with the proxy,
        create a thread to handle client to server data. This thead
        reads the first header of the request, and then opens a
        connection with the server, creating a second thread to handle
        the server to client data.

        If it is talking to a server, the thread handling client
        requests strips the domain name out of the URLs, and
        translates Proxy-Connection headers to Connection headers, and
        suppresses Upgrade headers. If it is talking to a chained
        proxy, it passes stuff as it is given, unless it needs to
        replace a "Keep-Alive" with a "Close" because it cannot figure
        the length.

        Similarly the server to client thread translates Connection to
        Proxy-Connection headers, and "Keep-Alive" to Close as needed.

        If the proxy-server connection closes expectedly (after having
        provided a response to each request) the server thread
        terminates.

        If the proxy-server connection closes unexpectedly (the server
        has nto provided a response to each request, the proxy-client
        connection is terminated, and both threads terminated.

        If the client thread closes expectedly or unexpectedly, both
        threads terminate and proxy-server connection is closed.

        If the client thread receives a new request when the server
        connection has already closed, and the server thread has
        terminated, it reopens the server thread and the server
        connection.
Received on Wed Aug 25 1999 - 19:02:26 MDT