Last time I asked about this I got the impression that I was 'on my own' and this
functionality wasn't included in a standard squid distribution:
In rough order of complexity:
1) Be able to log squid traffic to a file: not just headers or status, but content of
requests, posts, cookies, and responses to such.
ex.
log "all_traffic" (require quotes, " or ')
2) Allow more than files:
examples:
log "|my_logger_prog
log "|user@host:remoteprog args"
3) separate for 'from clients' / 'from servers'
ex:
log from [all] clients "äll_client_traff"
log from [all] servers "all_server_traff"
(3a) This could be evolved orthogonally with filter specs using etherfind or
ethereal type grammars (presumably, one more appropriate for squid, but this is a
tangent).
4) redirection (filtering), io-capture, _with_ _session_ _support_.
Conceptually, the simplest would be 1 process that handles 1
request at a time using 2 or 4 pipes (1 or 2 channels).
First) to pre-process a client request before being sent out to server.
Second) to post-process output from server before it is returned to the client.
Either stage being 'optional', of course if no <recording | logging |
processing> is desired.
A more detailed description _might_ be:
open 2, 4 or 6 "pipes" to 2nd process(es) used as follows:
---first squid receives request from client---
In any communication to a 'helper' process, a "SESSID" tag would be
pre-pended but removed before squid send text to server or client)
not in cache:
pipe 1: (squid)-> (proc) # (<SESSID>+raw client request)
pipe 2: (proc) -> (squid) # (<SESSID>+client request)
---squid sends request to server---
---squid gets reply from server---
pipe 3: (squid) -> (proc) # (<SESSID>+raw server text)
pipe 4: (proc) -> (squid) # (<SESSID>+server text to be
cached)
---squid caches data if needed---
in cache:
--squid retrieves data--
--then--
pipe 5: (squid) -> (proc) # (<SESSID>+server's reply (not cached mods))
pipe 6: (proc) -> (squid) # (<SESSID>+post cache processing)
---squid sends text to client as response---
Notes: SESSID tag could allow 1 "proc" to service multiple requests as
responses may be asynchronous.
Or...1 proc/session and no SESSID, but each invocation of 'proc' can only
handle 1 session at a time
I suppose this also could be looked at as a 'feature'(s) proposal -- I keep
rehashing it every several weeks but haven't gotten a chance to even look at doing it
myself (too much work for too few allowed keyboard hours-(RSI)). It's a pain when you
have more ideas than hand & coding power to implement.
Feel free to shred the design ideas with alternates -- I can either
justify, ask why, or just go "yeah, what 'they' said" and roll it into
any future plans/discussions...I'm a firm believer in going for quality of design --
though sometimes, I, like others, just settle for what barely scrapes by (yeah, I'm
part of the global software QA problem in that sense -- my expectations have been
lowered (*sigh*) ).
-Linda
