Doing some tests to use caddy + cache handler to cache deb packages from snapshot.debian.org.
It looks like in some cases, the client connection is being dropped after 10sec, resulting in the upstream connection to be dropped as well, and somehow the fragmentary response is still being saved in cache as valid.
Detailed info:
caddy version
f11c3c9f5a1be082450d64369853e1dacda22dde+modified (17 Aug 23 17:34 UTC)
{
admin off
skip_install_trust
order basicauth after request_header
order replace after encode
order cache before rewrite
log {
output stdout
format json
level debug
}
cache {
log_level debug
cache_keys {
.* {
disable_body
}
}
key {
disable_body
}
stale 31536000s
ttl 31536000s
nuts {
configuration {
Dir "/data/cache"
EntryIdxMode 1
RWMode 0
SegmentSize 1024
NodeNum 42
SyncEnable true
StartFileLoadingMode 1
}
}
}
}
http://: {
cache
reverse_proxy http://snapshot.debian.org {
header_up Host snapshot.debian.org:80
header_up -X-Forwarded-*
header_up -X-Real-IP
header_down -Server
}
}
On the client side, apt will reject the resource (since it does not match the expected hash) - that is how I noticed the issue.
Clearly, the resource has been inserted in the cache, but it should have not.
Doing some tests to use caddy + cache handler to cache deb packages from snapshot.debian.org.
It looks like in some cases, the client connection is being dropped after 10sec, resulting in the upstream connection to be dropped as well, and somehow the fragmentary response is still being saved in cache as valid.
Detailed info:
Here is the relevant part of the logs:
Hope I am not missing something obvious here.
On the client side, apt will reject the resource (since it does not match the expected hash) - that is how I noticed the issue. Clearly, the resource has been inserted in the cache, but it should have not.
Any insight here?
Thanks in advance.