Thanks for clarification on max-stale, although it is unintentionally ideal
for my use-case.
Best,
Robin
On Mon, 12 Feb 2024 at 16:06, Alex Rousskov <
rouss...@measurement-factory.com> wrote:
> On 2024-02-12 10:13, Robin Carlisle wrote:
>
> > I have been having success so far with the config
On 2024-02-12 10:13, Robin Carlisle wrote:
I have been having success so far with the config workaround.. config
snippet :-
/max_stale 31536000 seconds
refresh_pattern . 0 20% 4320 max-stale=31536000/
When an object has expired due to max-age and the PC is offline
(ethernet unplugged),
Hi,
I have been having success so far with the config workaround.. config
snippet :-
*max_stale 31536000 secondsrefresh_pattern . 0 20% 4320 max-stale=31536000*
When an object has expired due to max-age and the PC is offline (ethernet
unplugged), squid attempts an origin refresh and gives me
On 2024-02-09 08:53, Robin Carlisle wrote:
I am trying the config workaround approach.
Please keep us posted on your progress.
Below is the config snippet I have added. I made the
assumption that for the /refresh_pattern, max-stale=NN /config, the NN
is in minutes as per the rest of
Hi,
Thanks for the info Alex. Patching code and building is a little beyond me
tbh, especially as I would need this as a debian package to deploy to many
machines. With that in mind I am trying the config workaround approach.
Below is the config snippet I have added.I made the assumption
Hi Robin,
AFAICT from the logs you have privately shared and your squid.conf
that you have posted earlier, your Squid overwrites
stale-if-error=31536000 in the response with "refresh_pattern
max-stale=0" default. That 0 value is wrong. The correct value should be
taken from max_stale
On 8/02/24 07:45, Robin Carlisle wrote:
Hi,
I have just started my enhanced logging journey and have a small snippet
below that might illuminate the issue ...
/2024/02/07 17:06:39.212 kid1| 88,3| client_side_reply.cc(507)
handleIMSReply: origin replied with error 502, forwarding to client
On 2024-02-07 13:45, Robin Carlisle wrote:
I have just started my enhanced logging journey and have a small snippet
below that might illuminate the issue ...
/2024/02/07 17:06:39.212 kid1| 88,3| client_side_reply.cc(507)
handleIMSReply: origin replied with error 502, forwarding to client due
Hi,
I have just started my enhanced logging journey and have a small snippet
below that might illuminate the issue ...
*2024/02/07 17:06:39.212 kid1| 88,3| client_side_reply.cc(507)
handleIMSReply: origin replied with error 502, forwarding to client due to
fail_on_validation_err*
A few lines
Hi, thanks for your reply.
I have been looking at :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
*The stale-if-error response directive indicates that the cache can reuse a
stale response when an upstream server generates an error, or when the
error is generated
On 2024-02-01 12:03, Robin Carlisle wrote:
Hi, I am having trouble with stale-if-error response.
If I am interpreting Squid code correctly, in primary use cases:
* without a Cache-Control:stale-if-error=X in the original response,
Squid sends a stale object if revalidation results in a 5xx
Hi, I am having trouble with stale-if-error response. I am making calls
using curl to an API (under my control) on Amazon AWS. Config and details
below ...
# /etc/squid/squid.conf :
acl to_aws dstdomain .amazonaws.com
acl from_local src localhost
http_access allow to_aws
http_access allow
12 matches
Mail list logo
