<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/13/18 9:33 AM, Tom Scavo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEtu=dMXjWEzwgrBkpq1W=a5G=SBzGC-pBZHYcsu7JXmOuynig@mail.gmail.com"><br>
<blockquote type="cite">
<pre wrap="">1) If the metadata for the entity in question is still live and valid and
isn't past the point where the "next refresh" kicks in, then no HTTP request
is issued, so the IdP won't even know the metadata server is down.
</pre>
</blockquote>
<pre wrap="">
Do minCacheDuration and maxCacheDuration have an effect at this level
or the HttpCache level?
</pre>
</blockquote>
<br>
Yes, those 2 attributes control the behavior around when the
resolver attempts the "next refresh" (in addition to @validUntil and
@cacheDuration in the metadata). <br>
<br>
They do not have anything to do with the caching layer of
HttpClient.<br>
<br>
<blockquote type="cite"
cite="mid:CAEtu=dMXjWEzwgrBkpq1W=a5G=SBzGC-pBZHYcsu7JXmOuynig@mail.gmail.com">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">2) If the metadata *is* past the next refresh boundary, then an attempt is
made to re-fetch from the source. If it works, great, the live metadata is
updated accordingly. If it doesn't work as in your question (e.g. HTTP
client times out, etc), then nothing gets updated in the resolver. However,
if the live metadata is still valid, then it will continue to be used.
That's why we start trying to refresh the metadata *before* its
validity/cache expiration, via applying the refreshDelayFactor.
</pre>
</blockquote>
<pre wrap="">
Is the above behavior independent of the persistent cache? (I'm
guessing the answer is yes.)</pre>
</blockquote>
<br>
Yes, persistent cache has nothing to do with this.<br>
<blockquote type="cite"
cite="mid:CAEtu=dMXjWEzwgrBkpq1W=a5G=SBzGC-pBZHYcsu7JXmOuynig@mail.gmail.com"><br>
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Also, what happens if the server returns 304 Not Modified?
</pre>
</blockquote>
<pre wrap="">
Well, first off, you'd only see that if the HttpClient instance in use was
of the caching variety.
</pre>
</blockquote>
<pre wrap="">
Which it is by default, right?</pre>
</blockquote>
<br>
Yes, the IdP dynamic HTTP resolver defaults to the 'memory' caching
HttpClient instance.<br>
<br>
<blockquote type="cite"
cite="mid:CAEtu=dMXjWEzwgrBkpq1W=a5G=SBzGC-pBZHYcsu7JXmOuynig@mail.gmail.com">
<pre wrap="">
</pre>
<pre wrap="">
Right, that agrees with what Scott and Rod told me earlier, but that
is suboptimal since the metadata resolver redundantly processes the
metadata in the case of 304. That processing includes signature
verification and who knows whet other metadata filters have been
configured on the DynamicHTTPMetadataProvider. I'm not intimately
familiar with the implementation but there seems to be a significant
optimization lurking here, essentially the same optimization
implemented in FileBackedHTTPMetadataProvider.
</pre>
</blockquote>
<br>
Will respond to this in the next message.<br>
</body>
</html>