On 11/10/13 21:50, Wan-Teh Chang wrote:
> I would use a timeout of 5 seconds. 3 seconds seem a little short.
>
> I agree 10 seconds are too long.
Can you expand on what criteria you are using to make these judgements?
Fetching the OCSP response takes 2RTT, as Camilo said. So if your RTT is
1000m
On 10/11/13 1:58 PM, Eddy Nigg wrote:
On 10/11/2013 11:50 PM, From Wan-Teh Chang:
I would use a timeout of 5 seconds. 3 seconds seem a little short. I
agree 10 seconds are too long.
+1
Thanks Eddy/Wan Tech:
5 seconds seems too high for a fail open option, but let me ask you:
what percent o
On 10/11/13 1:39 PM, Bob Clary wrote:
On 10/11/2013 12:57 PM, Camilo Viecco wrote:
Hello List
I am planning to land a patch to reduce the default (soft-fail) OCSP
network timeout values. Currently OCSP connections timeout after 10
seconds and my plan is to changed that to 3 seconds (hard fail w
On 10/11/2013 11:50 PM, From Wan-Teh Chang:
I would use a timeout of 5 seconds. 3 seconds seem a little short. I
agree 10 seconds are too long.
+1
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_ni
On 10/11/2013 12:57 PM, Camilo Viecco wrote:
Hello List
I am planning to land a patch to reduce the default (soft-fail) OCSP
network timeout values. Currently OCSP connections timeout after 10
seconds and my plan is to changed that to 3 seconds (hard fail will keep
the current 10 second timeout
Hello List
I am planning to land a patch to reduce the default (soft-fail) OCSP
network timeout values. Currently OCSP connections timeout after 10
seconds and my plan is to changed that to 3 seconds (hard fail will keep
the current 10 second timeout value).
With this change (according to te
6 matches
Mail list logo