Hey Henrik, Thanks for the info. I am aware but that these are TCP level identifiers. I digged into it and saw that class HttpRequest has members client_ip, host_ip, port and my_addr. Client_ip is very obvious and i can see that the X-Client-IP field is populated with it. What about the following fields host_ip: is this the ip of the origin server to which the request is going? And will it remain same in the response? port: is this the port from which the request originated? Source port of the request? What will be the value in response from the server? my_addr: This seems like the ip on which squid is listening. Correct me if i am wrong How to get destination port. It is either http (80) or https(443). But how can i differentiate? How do i know what was the destination port of the request? -talha On Wed, Apr 18, 2012 at 1:22 PM, Henrik Nordström <henrik@xxxxxxxxxxxxxxxxxxx> wrote: > ons 2012-04-18 klockan 11:08 +0500 skrev Ahmed Talha Khan: > >> I want to extract session 5-tuples inside squid and send them to an >> ICAP servers as an argument to the service being invoked. By session >> 5-tuple i mean the following >> >> Source IP >> Destination IP, >> Source Port, >> Destination Port, >> Protocol >> >> for a specific HTTP request. These are the 5-tuples that uniquely >> identify a traffic flow. Is there a way to do it? Any place i can put >> such hooks? Or does squid have some other way of identifying >> individual requests from different IPs/Ports ? > > The above identifies a flow at TCP level, not a request. Within a flow > there may be multiple requests (connection keep-alive), or even for > different clients when there is a proxy involved. > > It's further complicated by Squid being a proxy, so you have two > independent TCP flows, client<->squid, and squid<->nexthopserver, and > depending on which ICAP hook you use and the details of the > request/response you may have any combination of the two available > within Squid. > > To simplify matters to a manageable level most selects to identify > requests by the following tuple instead > > - Time, high resolution and NTP controlled. > - Requesting IP (and optionally port but usually port is ignored). > - Requested URL > > This is generally sufficient to identify a single request even in high > traffic environments, even if there is a chance of collisions. > > Information about the requesting client IP is sent as part of the ICAP > transaction by default in the X-Client-IP ICAP header. Maybe you also > have client information in the X-Forwarded-For HTTP request header. > > If you want to add more informaition then > Adaptation::Icap::ModXact::makeRequestHeaders is the method where the > ICAP request headers is filled in. > > Regards > Henrik > -- Regards, -Ahmed Talha Khan
