client_side_reply and processing of reply headers / body

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

Regards
Henrik
Received on Thu Oct 17 2002 - 02:01:19 MDT