Re: client_side_reply and processing of reply headers / body

On Thu, 2002-10-17 at 18:01, Henrik Nordstrom wrote:
> I am trying to update rproxy to Squid-2-HEAD to have a semi-stable
> version before porting to Squid-3, but run into some issues with the
> reply data path in client_side_reply.
>
> In the rproxy patch I have separated processing of reply headers from
> processing of reply data in two different functions,
> clientSendMoreHeaderData() and clientSendMoreData(). When the headers
> are parsed a long blocking chain of different processing steps kicks
> in for
>
> * http_reply_access (aclNBCheck)
> * Location header rewrite, with a aclNBCheck check..
>
> and there is also
>
> * Error page substitution, replacing the body of the error with
> another body (a second HTTP request is initiated for the new body).
>
> Trying to figure out how to fit this in the new "client reply stream"
> scheme of things..

OK, it's fairly easy :}.

firstly, you'll want to look at the hook used by the ESI code. (Start by
grepping for ESI in client_side_reply.c in the s.f. esi branch.

The reply headers and data are separated here too. Rather than separate
functions, there is a single chain.

When responding to a read request from the client, each node in the
chain provides headers and or data. Each node can buffer as much as it
wants to. The semantics are:
The first response MUST include an HttpReply pointer.
Only the first response includes an HttpReply pointer.
The HttpReply ownership is handed off as it passes down the stream. The
tail of the chain frees it.
This allows each node to alter the reply as it sees fit.

Data can be provided in any response, up to the amount requested by the
client.

Only one response is allowed per read request.

Does that help? (This is whats in the prog guide IIRC).

Rob