Re: protocol clarity

On Sun, 2006-09-10 at 21:40 +1000, Robert Collins wrote:
> So I've finished my analysis of the protocol stuff in squid - protocol_t
> etc.
>
> http://wiki.squid-cache.org/ForwardRework has some thoughts about how we
> can improve the current api, to make SSL fit in more cleanly, and make
> doing some nifty things, like forwarding via ssh tunnels, or peers that
> need a vpn etc, easy to do.

Do you perceive any related significant changes to the ICAP code?

Squid implements an ICAP client, but the ICAP implementation differs
from other protocols because ICAP is not a "forward-and-forget" protocol
or, at least, it cannot be implemented that way today (perhaps
unfortunately).

Today, the client- and server-side HTTP code pipes the HTTP message to
ICAP and expects a new message to be piped back, possibly at the same
time. Various ICAP aborts are rather difficult to recover from today. It
would be nice if your scheme would help with that.

Another issue is message data copying. Today, HTTP bodies are copied
when they go to ICAP and are copied again when they go back to HTTP,
even though the content is known to be identical (e.g., the ICAP server
said 204 "No Content"). I am not sure whether this should be optimized
on the MemBuf level (i.e., optimize copying itself via lazy copying and
such) or on a protocol-handling level (i.e., remove the need for
copying). The latter approach may seem better from the design point of
view, but is far more difficult to implement with the existing code; we
currently do not have sane means of sharing the same I/O buffer among
three protocols (HTTP client, HTTP server, and ICAP client).

Thank you,

Alex.
Received on Tue Oct 10 2006 - 09:24:58 MDT