Hey Moti, It is a good assumption that the same caching dns server (not 8.8.8.8 or 1.1.1.1) that the client use will return the relevant destination ip for the domain. Its possible to do such a query in the icap service with low timeout(2-3) seconds. can this be good enough for your use case?
Eliezer On Mon, Jan 18, 2021, 00:28 Moti Berger <mober...@metanetworks.com> wrote: > Hi > > My goal is to obtain the destination IP when sending an HTTP request for > my ICAP server so it would be able to decide the kind of adaptation > required based on it. > > Looking at squid (5.0.4) code I discovered the following: > > It seems that "everything" starts at ClientRequestContext. > I've noticed that noteAdaptationAclCheckDone calls startAdaptation which > calls more methods, eventually getting > to Adaptation::Icap::ModXact::makeRequestHeaders where it iterates over > headers defined by the adaptation_meta configurations in squid.conf. > For each, it calls the 'match' method where it tries to format (and > assemble) it. There it seems that the value is taken from an AccessLogEntry: > >> case LFT_SERVER_IP_ADDRESS: >> if (al->hier.tcpServer) >> out = al->hier.tcpServer->remote.toStr(tmp, sizeof(tmp)); >> break; >> > > So the AccessLogEntry object seems to be the key. > At REQMOD time, I don't get the value of the destination IP. > Looking further I found that the DNS resolving happens when it's decided > that the request should be forwarded to the destination server. > > So I tracked the flow and it seems to start from FwdState::Start method > which gets an AccessLogEntryPointer. > Then it calls methods that eventually do the DNS resolving > (Dns::nbgethostbyname) and ending in (FwdState::connectStart) which have > the IP to connect to. > So it seems that this flow will populate the AccessLogEntry. > This seems right since during RESPMOD, the same code above > (in Adaptation::Icap::ModXact::makeRequestHeaders) is running and this time > the `match` method eventually gets the destination IP. > I added logs that prints the AccessLogEntryPointer and in the FwdState.cc > the log says address 0x5592ab521e30*12 and in the Notes.cc the log says > address 0x5592ab521e30*25. > > Two things that I haven't found yet: > 1. The place where the AccessLogEntry is populated > 2. Where after the adaptation, the forwarding to the destination server > occured (assuming it should be forwarded) > > I couldn't figure out a way to start the DNS resolving just before > the startAdaptation starts as it requires all sorts of objects that seem to > be unavailable there. > I wonder if you can help me to find a way to do it. > > Thanks, > Moti > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
