On 1/28/21 1:34 PM, Milos Dodic wrote: > I have noticed that the test server also doesn't cache anything > So if I try to go for a file in S3, it says MISS, and after that, MISS > again, and I see no new objects in cache being created. > If I try the same thing from the proxy itself, I get the MISS, and the > object gets cached, as it should. > When I go back to the test server, and try again, it sees the object in > cache and returns TCP_MEM_HIT/200 instead. Without more details, I can only speculate that the client running on the test server sends different HTTP request headers than the client running on the proxy itself. You can see the headers in cache.log if you set debug_options to ALL,2. If you are not sure whether they are the same, please share those logs. They will also contain response headers and other potentially useful details. If the request headers are the same in both tests, then I would recommend sharing compressed ALL,7 or ALL,9 debugging logs of both successful and unsuccessful tests (four transactions, two logs) for analysis. Do not use sensitive data for these tests. https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction Alex. > This is the entire config file: > > > visible_hostname squid > cache_dir ufs /test/cache/squid 10000 16 256 > > http_access allow localhost > http_access alow all > > http_port 3128 > http_port 3129 intercept > acl allowed_http_sites dstdomain .amazonaws.com <http://amazonaws.com> > http_access allow allowed_http_sites > > https_port 3130 cert=/etc/squid/ssl/squid.pem ssl-bump intercept > acl SSL_port port 443 > http_access allow SSL_port > acl allowed_https_sites ssl::server_name .amazonaws.com > <http://amazonaws.com> > > ssl_bump stare all > ssl_bump bump allowed_https_sites > ssl_bump terminate all > On Tue, Jan 26, 2021 at 9:14 PM Alex Rousskov wrote: > > On 1/26/21 1:54 PM, Milos Dodic wrote: > > > when the test server goes for a picture I have stored somewhere in > > the cloud, the squid access log shows "TCP_TUNNEL/200". But when I > > try from the proxy itself with squidclient tool, I get > > "TCP_MEM_HIT/200" > > > Given the very limited information you have provided, I am guessing that > > * the primary tests opens a CONNECT tunnel through Squid > * the squidclient test sends a plain text HTTP request to Squid > > The final origin server destination may be the same in both tests, but > the two transactions are completely different from Squid point of view. > > > > ssl_bump peek step1 all > > ssl_bump peek step2 allowed_https_sites > > ssl_bump splice step3 allowed_https_sites > > ssl_bump terminate step3 all > > > AFAICT, this configuration is splicing or terminating all TLS traffic. > No bumping at all. If you want your Squid to bump TLS tunnels, then you > have to have at least one "bump" rule! > > I do not know what your overall SslBump needs are, but perhaps you meant > something like the following? > > acl shouldBeBumped ssl::server_name .amazonaws.com > <http://amazonaws.com> > > ssl_bump stare all > ssl_bump bump shouldBeBumped > ssl_bump terminate all > > Please do not use the configuration above until you understand what it > does. Please see https://wiki.squid-cache.org/Features/SslPeekAndSplice > for details. > > Depending on your environment, the http_access rules may need to be > adjusted to allow CONNECT requests (to TLS-safe ports) to IP addresses > that do not result in .amazonaws.com <http://amazonaws.com> in > reverse DNS lookups. > > > HTH, > > Alex. > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
