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.