Configuration directive allow to update it less or _more_ frequently if
required.
At the moment nobody knows how often are OCSP responses updated until check
the source code b/c there is no word in documentation about it.
On Mon, Jan 13, 2014 at 10:25 PM, Maxim Dounin wrote:
> Hello!
>
> On M
Hello!
On Mon, Jan 13, 2014 at 08:23:46PM +0400, kyprizel wrote:
> > This looks like a very-very wrong way to address the problem.
> > Instead of resolving the problem it will hide it on some requests
> > (but not on others), making the problem harder to detect and debug.
>
> Once user can acces
Hello!
On Mon, Jan 13, 2014 at 07:45:29PM +0400, kyprizel wrote:
> The reason is quite easy - most responders _do_ set validity time equal to
> 7 days and there is no reason to update the response every hour and I want
> to update it more rarely.
> Some do not set nextUpdate at all and 3600 can b
> This looks like a very-very wrong way to address the problem.
> Instead of resolving the problem it will hide it on some requests
> (but not on others), making the problem harder to detect and debug.
Once user can access the resource - he can see the warning about system
time problem (and other
The reason is quite easy - most responders _do_ set validity time equal to
7 days and there is no reason to update the response every hour and I want
to update it more rarely.
Some do not set nextUpdate at all and 3600 can be too rarely for them.
On Mon, Jan 13, 2014 at 7:42 PM, Maxim Dounin wr
Hello!
On Mon, Jan 13, 2014 at 07:04:11PM +0400, kyprizel wrote:
> So, you going to leave 3600 hardcoded there?
Yes, unless you have some better reasons to make it
configurable.
>
>
> On Mon, Jan 13, 2014 at 6:51 PM, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Mon, Jan 13, 2014 at 06:08:53
So, you going to leave 3600 hardcoded there?
On Mon, Jan 13, 2014 at 6:51 PM, Maxim Dounin wrote:
> Hello!
>
> On Mon, Jan 13, 2014 at 06:08:53PM +0400, kyprizel wrote:
>
> > "some cases", for example = you have a lot of users with wrong system
> time,
> > so they can't access the server if OCS
Hello!
On Mon, Jan 13, 2014 at 06:08:53PM +0400, kyprizel wrote:
> "some cases", for example = you have a lot of users with wrong system time,
> so they can't access the server if OCSP responses updated too frequently.
This looks like a very-very wrong way to address the problem.
Instead of re
"some cases", for example = you have a lot of users with wrong system time,
so they can't access the server if OCSP responses updated too frequently.
According to validity time - most responders issue OCSP response valid for
7 days, but they also can issue responses without nextUpdate option.
I th
Hello!
On Sat, Jan 11, 2014 at 07:52:12PM +0400, kyprizel wrote:
> In some cases we need to vary period after OCSP response will be refreshed.
> By default it was hardcoded to 3600 sec. This directive allows to change it
> via config.
In which "some cases"? The directive was ommitted intentiona
In some cases we need to vary period after OCSP response will be refreshed.
By default it was hardcoded to 3600 sec. This directive allows to change it
via config.
Also, there were some kind of bursts when all the cluster nodes and nginx
workers go to update their OCSP staples - random delay withi
11 matches
Mail list logo
