SP V3 metadata types

[Brent Putman]

On 6/13/18 9:33 AM, Tom Scavo wrote:
>
>> 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.
> Do minCacheDuration and maxCacheDuration have an effect at this level
> or the HttpCache level?

Yes, those 2 attributes control the behavior around when the resolver
attempts the "next refresh" (in addition to @validUntil and
@cacheDuration in the metadata). 

They do not have anything to do with the caching layer of HttpClient.

>> 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.
> Is the above behavior independent of the persistent cache? (I'm
> guessing the answer is yes.)

Yes, persistent cache has nothing to do with this.
>
>>> Also, what happens if the server returns 304 Not Modified?
>> Well, first off, you'd only see that if the HttpClient instance in use was
>> of the caching variety.
> Which it is by default, right?

Yes, the IdP dynamic HTTP resolver defaults to the 'memory' caching
HttpClient instance.

> 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.

Will respond to this in the next message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20180614/cb767fe7/attachment.html>