> On 12 Jun 2022, at 02:52, Maxim Dounin wrote:
>
> Hello!
>
> On Fri, Jun 10, 2022 at 03:37:34PM +0400, Sergey Kandaurov wrote:
>
> [...]
>
>> # HG changeset patch
>> # User Sergey Kandaurov
>> # Date 1654860778 -14400
>> # Fri Jun 10 15:32:58 2022 +0400
>> # Node ID f8e5ab69e6edd379b
Hello!
On Fri, Jun 10, 2022 at 03:37:34PM +0400, Sergey Kandaurov wrote:
> > On 8 Jun 2022, at 04:57, Maxim Dounin wrote:
> >
> > On Tue, Jun 07, 2022 at 07:58:36PM +0400, Sergey Kandaurov wrote:
[...]
> > Also, it might be a good idea to make sure that various
> > other factors to disable c
> On 8 Jun 2022, at 04:57, Maxim Dounin wrote:
>
> Hello!
>
> On Tue, Jun 07, 2022 at 07:58:36PM +0400, Sergey Kandaurov wrote:
>
>>> On 7 Jun 2022, at 01:09, Maxim Dounin wrote:
>>>
>>> On Mon, Jun 06, 2022 at 05:42:20PM +0400, Sergey Kandaurov wrote:
>>>
On Sun, Apr 24, 2022 at 06:4
Hello!
On Tue, Jun 07, 2022 at 07:58:36PM +0400, Sergey Kandaurov wrote:
> > On 7 Jun 2022, at 01:09, Maxim Dounin wrote:
> >
> > On Mon, Jun 06, 2022 at 05:42:20PM +0400, Sergey Kandaurov wrote:
> >
> >> On Sun, Apr 24, 2022 at 06:42:47PM +0300, Maxim Dounin wrote:
> >>> Hello!
> >>>
> >>> O
> On 7 Jun 2022, at 01:09, Maxim Dounin wrote:
>
> Hello!
>
> On Mon, Jun 06, 2022 at 05:42:20PM +0400, Sergey Kandaurov wrote:
>
>> On Sun, Apr 24, 2022 at 06:42:47PM +0300, Maxim Dounin wrote:
>>> Hello!
>>>
>>> On Sun, Apr 24, 2022 at 07:55:17AM +0300, Maxim Dounin wrote:
>>>
>>> [...]
>
Hello!
On Mon, Jun 06, 2022 at 05:42:20PM +0400, Sergey Kandaurov wrote:
> On Sun, Apr 24, 2022 at 06:42:47PM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Sun, Apr 24, 2022 at 07:55:17AM +0300, Maxim Dounin wrote:
> >
> > [...]
> >
> > > As far as I can tell, proper behaviour, assuming we
> On 6 Jun 2022, at 17:42, Sergey Kandaurov wrote:
>
> On Sun, Apr 24, 2022 at 06:42:47PM +0300, Maxim Dounin wrote:
>> Hello!
>>
>> On Sun, Apr 24, 2022 at 07:55:17AM +0300, Maxim Dounin wrote:
>>
>> [...]
>>
>>> As far as I can tell, proper behaviour, assuming we parse cache
>>> control e
On Sun, Apr 24, 2022 at 06:42:47PM +0300, Maxim Dounin wrote:
> Hello!
>
> On Sun, Apr 24, 2022 at 07:55:17AM +0300, Maxim Dounin wrote:
>
> [...]
>
> > As far as I can tell, proper behaviour, assuming we parse cache
> > control extensions independently of X-Accel-Expires, can be
> > implement
Hi Maxim!
Thanks for the update, I will make some production tests soon but for now I can
say that tests from test-suit are passing which is great!
Best wishes,
Vadim
On 24.04.2022 16:42, Maxim Dounin wrote:
Hello!
On Sun, Apr 24, 2022 at 07:55:17AM +0300, Maxim Dounin wrote:
[...]
As fa
Hi Yugo!
I will disagree with your comment. If X-Accel-Expires has value 0 then
r->cacheable will be zeroed and no caching will occur anyway and the valid_sec
will never be checked. Overall the patch looks like a simplified version of what
we already had, which is great!
Best wishes,
Vadim
Hello,
I appriciate deeply with two of your cooperation.
Maxim's patch looks good to see but it seems to be a bit weird about the
behavior of the r->cache->valid_sec.
In case of the `X-Accel-Expires: 0` header comes first than the
`Cache-Control: max-age=10` header, the r->cache->valid_sec could n
Hello!
On Sun, Apr 24, 2022 at 07:55:17AM +0300, Maxim Dounin wrote:
[...]
> As far as I can tell, proper behaviour, assuming we parse cache
> control extensions independently of X-Accel-Expires, can be
> implemented by using just one flag.
No, that's wrong, as with just one flag it wouldn't
Hello!
On Fri, Apr 22, 2022 at 08:06:08PM +0100, Vadim Fedorenko via nginx-devel wrote:
> Hi Maxim!
>
> Thanks for the feedback. As you might have already seen, I sent another
> version
> of this patch which addresses some of style and readability issues as well as
> X-Accel-Expires issue in v3
Hi Maxim!
Thanks for the feedback. As you might have already seen, I sent another version
of this patch which addresses some of style and readability issues as well as
X-Accel-Expires issue in v3.
Regarding RFC issue. RFC 7234 Section 5.1 explicitly states that Expires MUST be
ignored if reponse
Hello!
On Tue, Apr 19, 2022 at 10:59:12PM +0100, Vadim Fedorenko wrote:
> On 19.04.2022 16:01, Maxim Dounin wrote:
> >
> > On Sun, Apr 17, 2022 at 08:50:25PM +0100, Vadim Fedorenko via nginx-devel
> > wrote:
> >
> >> On 17.04.2022 02:55, Maxim Dounin wrote:
> >>
> >>> I'm quite sceptical about
Hello!
On Sun, Apr 17, 2022 at 08:50:25PM +0100, Vadim Fedorenko via nginx-devel wrote:
> On 17.04.2022 02:55, Maxim Dounin wrote:
>
> > I'm quite sceptical about attempts to fix this by introducing
> > various flags and reverting cacheable status back to 1. This is
> > not how it should be fix
Hi, Vadim.
Thanks for your cooperation!
> @@ -5067,6 +5091,7 @@
> || (h->value.len == 1 && h->value.data[0] == '*'))
> {
> u->cacheable = 0;
> +u->cacheable_reason |= NGX_HTTP_CACHEABLE_VARY;
> }
> I don't see any reasons to store information about "Vary" heade
Hi Yugo!
Looks like another solution with the same concept - store additional information
about several headers. The second patch you proposed looks a bit overcomplicated
inside this additional function. I don't see any reasons to store information
about "Vary" header. AFAIU, weed special informa
We're also interested in this issue because the CDN provider like us is
concerned about the problems with the headers that determine the cache
freshness.
It is often a serious problem used in Nginx as the origin server or the
intermediate cache server that has such problems.
In those days, we also
Hi Maxim!
On 17.04.2022 02:55, Maxim Dounin wrote:
Hello!
[...]
Thanks for the patch.
I'm quite sceptical about attempts to fix this by introducing
various flags and reverting cacheable status back to 1. This is
not how it should be fixed.
Yeah, the solution might be a bit complicated, bu
Hello!
On Fri, Apr 15, 2022 at 02:02:53AM +0300, Vadim Fedorenko via nginx-devel wrote:
> # HG changeset patch
> # User Vadim Fedorenko
> # Date 1649889268 -10800
> # Thu Apr 14 01:34:28 2022 +0300
> # Node ID ed7a2c031475bcb252952a467c184c94652b926a
> # Parent a736a7a613ea6e182ff86fbadcb9
# HG changeset patch
# User Vadim Fedorenko
# Date 1649889268 -10800
# Thu Apr 14 01:34:28 2022 +0300
# Node ID ed7a2c031475bcb252952a467c184c94652b926a
# Parent a736a7a613ea6e182ff86fbadcb98bb0f8891c0b
Upstream: prioritise Cache-Control over Expires.
RFC7234 explicitly says that cache reci
22 matches
Mail list logo
