Re: [squid-users] Supported configuration for adding origin server IP in response header
On Thu, Oct 16, 2014 at 1:53 PM, Amos Jeffries wrote: >> I view the Via header as similar to the Received header in SMTP. >> In this case it's added by other proxies/caches, correct? > > Thats a good analogy, but not quite. It MUST be added by all proxies > including Squid. > > http://tools.ietf.org/html/rfc7230#section-5.7.1 paragraphs 3 and 5. > > In squid.conf simply remove any "via off" you may have. The default is > to comply with the RFC "MUST send" criteria. The Via header indicates proxies/caches/gateways which have handled the message between the requestor and the origin server. I do not require this information; is there a way to configure squid to indicate the IP address of the origin server in a response header? Darren ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Supported configuration for adding origin server IP in response header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/10/2014 9:29 a.m., Darren Spruell wrote: > On Thu, Oct 16, 2014 at 12:40 PM, Amos Jeffries > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 17/10/2014 8:10 a.m., Darren Spruell wrote: >>> Had a use case to ask about, apologies if I missed in docs. Is >>> there a configuration that allows squid running as forward >>> proxy to add a custom response header containing the origin >>> server IP address that served the resource? Assuming no cache >>> hierarchy. >>> >>> In the event that the resource is served from cache, would be >>> interesting if squid were able to track the IP address from >>> which the cached resource was originally retrieved to include >>> in responses. In the event that's not possible, then the IP >>> address of the cache itself as well as an indication that the >>> resource was served from cache rather than an upstream origin. >>> >>> Most resources seem to cover including this information in the >>> access log, however I'm interested in having the data in the >>> HTTP response for this case. >>> >> >> IP address is not much useful in the response - any given machine >> has multiple of those and they are also shared between anycast >> servers or load balancers. > > Usefulness (utility) is in the eye of the beholder. :) > >> It is also a mistake to think of "the" server as being one >> machine. It is becomming extremely popular to use CDN services >> these days. CDN are reverse-proxy services in one form or >> another. So "the" server may be a chain of servers on some path >> through a server farm. > > In my case, those abstractions are not significant. The goal is > determining, for a client behind a forward proxy, can the proxy > simply inform the client of the IP address to which the proxy > connected to fetch the resource? The IP address is the key data > element for this case. Even with a CDN the IP address of the > frontend is fine. > >> 1) The Via header is closest to what you are seeking. In >> responses it contains each servers FQDN or an unique alias. It is >> supposed to contain a record of the whole chain of machines the >> message traversed. - The problem is that a lot of admin disable >> it or strip it out of the traffic. So you may get a proper chain >> or only what your proxy is adding, with no easy way to identify >> missing chain data. > > I view the Via header as similar to the Received header in SMTP. > In this case it's added by other proxies/caches, correct? Thats a good analogy, but not quite. It MUST be added by all proxies including Squid. http://tools.ietf.org/html/rfc7230#section-5.7.1 paragraphs 3 and 5. In squid.conf simply remove any "via off" you may have. The default is to comply with the RFC "MUST send" criteria. Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUQDBQAAoJELJo5wb/XPRjZqEH+QFbiYfRdd0t+ki+q6tN8TKQ I5XLxJSrF+yoYjbHb1neJgu1Y2wwfU2cEUgaG5fJhAHpVrdk4/0PdmU6K5aFFs/M 8FD3mDd+Ur/Vwapc55G9GpCis9fr747Yz5mDuqgrSA7JHyHKENUxS09umCvdiB0a VJmhxjhjOCZFc8Gj/qfvoz3orHwlNDY1ziMkCDIQW6pmwpi61yOust26faRq73yT TnYKNHCaK9R/ZZ3bQlGQCiWMTdbYcBdD3bxnlG5TaB4xxyTIOxWj1WGmJ3l4Ho8P gRbk2oNdMrNttXWCeGSt76XuymLY8oQ2RA4IToO1PQMO2QzsxfN1k+uE88pz+lk= =FC/N -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Supported configuration for adding origin server IP in response header
On Thu, Oct 16, 2014 at 12:40 PM, Amos Jeffries wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 17/10/2014 8:10 a.m., Darren Spruell wrote: >> Had a use case to ask about, apologies if I missed in docs. Is >> there a configuration that allows squid running as forward proxy to >> add a custom response header containing the origin server IP >> address that served the resource? Assuming no cache hierarchy. >> >> In the event that the resource is served from cache, would be >> interesting if squid were able to track the IP address from which >> the cached resource was originally retrieved to include in >> responses. In the event that's not possible, then the IP address of >> the cache itself as well as an indication that the resource was >> served from cache rather than an upstream origin. >> >> Most resources seem to cover including this information in the >> access log, however I'm interested in having the data in the HTTP >> response for this case. >> > > IP address is not much useful in the response - any given machine has > multiple of those and they are also shared between anycast servers or > load balancers. Usefulness (utility) is in the eye of the beholder. :) > It is also a mistake to think of "the" server as being one machine. It > is becomming extremely popular to use CDN services these days. CDN are > reverse-proxy services in one form or another. So "the" server may be > a chain of servers on some path through a server farm. In my case, those abstractions are not significant. The goal is determining, for a client behind a forward proxy, can the proxy simply inform the client of the IP address to which the proxy connected to fetch the resource? The IP address is the key data element for this case. Even with a CDN the IP address of the frontend is fine. > 1) The Via header is closest to what you are seeking. In responses it > contains each servers FQDN or an unique alias. It is supposed to > contain a record of the whole chain of machines the message traversed. > - The problem is that a lot of admin disable it or strip it out of > the traffic. So you may get a proper chain or only what your proxy is > adding, with no easy way to identify missing chain data. I view the Via header as similar to the Received header in SMTP. In this case it's added by other proxies/caches, correct? But I have no cache hierarchy, and simply need the IP address of the origin server. Squid knows what it is, because it opens a socket to it. It can filter it with ACLs. It can log it in the access log. Can it add it into a response header? DS ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Supported configuration for adding origin server IP in response header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/10/2014 8:10 a.m., Darren Spruell wrote: > Had a use case to ask about, apologies if I missed in docs. Is > there a configuration that allows squid running as forward proxy to > add a custom response header containing the origin server IP > address that served the resource? Assuming no cache hierarchy. > > In the event that the resource is served from cache, would be > interesting if squid were able to track the IP address from which > the cached resource was originally retrieved to include in > responses. In the event that's not possible, then the IP address of > the cache itself as well as an indication that the resource was > served from cache rather than an upstream origin. > > Most resources seem to cover including this information in the > access log, however I'm interested in having the data in the HTTP > response for this case. > IP address is not much useful in the response - any given machine has multiple of those and they are also shared between anycast servers or load balancers. It is also a mistake to think of "the" server as being one machine. It is becomming extremely popular to use CDN services these days. CDN are reverse-proxy services in one form or another. So "the" server may be a chain of servers on some path through a server farm. 1) The Via header is closest to what you are seeking. In responses it contains each servers FQDN or an unique alias. It is supposed to contain a record of the whole chain of machines the message traversed. - The problem is that a lot of admin disable it or strip it out of the traffic. So you may get a proper chain or only what your proxy is adding, with no easy way to identify missing chain data. 2) If the respone contains an Age: header then it has been cached. 3) Squid also adds X-Cache* headers indicating HIT/MISS status. But those contain misinformation on REFRESH'd responses. Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUQB9EAAoJELJo5wb/XPRjoWsIANzZ03aSY1nHb6p9pDXGSKmu 4klFIaQSRi5VKQn2pbZljzxfoAO3Ev3sQBdbyoXzw14cv4EKXA9l5Jj+Q/XjG8Lh ab07tcdordERsmH3iUmSpgOwRxvBoEI5HKqeKli4S37JjHOnZ+l/oU2MYZ2LTyJ7 pmnCWOJURjLlPBfEWCzh8eI6M1c5v56kS77qINapjK3qVqoc7UO5wYUTEm/S6iSX EhmsIxrkCH4K3lZo74Krz4/sBcDViSZpfYE9SZeKlq9pakSH3uH4PU9Jw1qHYm6P KE7clU+5DNMm6q0YR6z0GE0vw/8xFFrWkCCxXagRF0dOlbgIfE75w0nyy4k+jTg= =s0Ul -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users