Search squid archive

Re: 3.5.28 partial content getting HIT but not sending

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hum, disabling that refresh_pattern and -k reconfigure seems to have fixed it.. but.. why?


-- 
Atenciosamente,

Heiler Bensimon Bemerguy - CINBESA
Analista de Redes, Wi-Fi,
Virtualização e Serviços Internet
(55) 91 98151-4894
Em 23/11/2018 14:02, Heiler Bemerguy escreveu:

I got today these hits repeating all day long:

1542992067.660      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542992067.717      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip
1542992067.779      1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip

a tcpdump shows me a partial get from client:

GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz HTTP/1.1
Host: archive.canonical.com
Range: bytes=3790651-
If-Range: Tue, 20 Nov 2018 13:54:54 GMT
User-Agent: Debian APT-HTTP/1.3 (1.6.6)


and proxy anwers like this:

HTTP/1.1 206 Partial Content
Date: Thu, 22 Nov 2018 10:40:20 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Tue, 20 Nov 2018 13:54:54 GMT
ETag: "1d1c25d-57b18fa72c3e2"
Accept-Ranges: bytes
Content-Type: application/x-gzip
Age: 108770
Warning: 113 proxy (squid) This cache hit is still fresh and more than 1 day old
Connection: keep-alive
Content-Range: bytes 3790651-30523996/30523997
Content-Length: 26733346

But there isn't much being transfered after it. And it should transfer 26,733,346 bytes, right? But look at the tcp packet capture right after the above one:

13:53:10.070860 IP 10.1.10.9.3080 > 10.15.3.137.43098: Flags [F.], seq 428, ack 254, win 33, options [nop,nop,TS val 70122782 ecr 1622121716], length 0
E..4c.@.@..E
.

......Z.-.qpl"Z...!!......
.-..`...
13:53:10.085478 IP 10.15.3.137.43098 > 10.1.10.9.3080: Flags [.], ack 428, win 237, options [nop,nop,TS val 1622121737 ecr 70122782], length 0
E..4..@.?...
...
.
        .Z..pl"Z.-.q.....a.....
`..     .-..
13:53:10.103003 IP 10.15.3.137.43098 > 10.1.10.9.3080: Flags [F.], seq 254, ack 429, win 237, options [nop,nop,TS val 1622121737 ecr 70122782], length 0
E..4..@.?...
...
.
        .Z..pl"Z.-.r....._.....
`..     .-..
13:53:10.103024 IP 10.1.10.9.3080 > 10.15.3.137.43098: Flags [.], ack 255, win 33, options [nop,nop,TS val 70122790 ecr 1622121737], length 0

It seems the proxy just closes the connection, then the client connects again and tries to get the same part everytime... There's nothing unusual on cache*.log

I think this file type is being "treated" by this pattern_refresh, I don't know if it would mess with anything, I think probably not:

refresh_pattern -i \.(udeb|exe|ms[iup]|xz|xml|bz2|gz|deb|rpm|bin|zip|ax|rpm|app|jar|pkg|apk|mar|nzp|dat|iop|xpi|dmg|dds|rar|thor|nar|gpf|lzma2)\??$ 120960 90% 120960 ignore-no-store ignore-private override-e
xpire store-stale override-lastmod

-- 
Atenciosamente,

Heiler Bensimon Bemerguy - CINBESA
Analista de Redes, Wi-Fi,
Virtualização e Serviços Internet
(55) 91 98151-4894


_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux