SP V3 metadata types

[Tom Scavo]

On Tue, Jun 12, 2018 at 2:16 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>>
>> On 6/12/18 10:01 AM, Tom Scavo wrote:
>>
>> In any case, I'm not sure I understand this well enough to document
>> it. Can you describe what happens if the server goes down for, say, 20
>> mins?
>
> I think there's 3 cases:
>
> 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?

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

> 3) If the server is down and the refresh attempt fails and the metadata
> in-memory is expired/invalid, then no entity is returned from that resolver.

Yes, that makes sense.

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

> It's the HttpClient that would decide to issue a
> conditional GET, not the resolver.  As discussed extensively in another
> thread, the dynamic HTTP resolver code itself does not cache/utilize
> Last-Modified and ETag nor does it do conditional GET internally; it
> delegates all that to the HttpClient instance.

Yes, I understand that now.

> So, the dynamic HTTP resolver itself will not really see or handle any 304,
> it's a matter for the HttpClient instance.  If the latter is of the caching
> variety and it issues a conditional GET and gets a 304, then it's going to
> return the previously cached HTTP response to the resolver.  The metadata
> resolver itself won't know or care whether the HTTP response came from a
> "real" fetch that returned a 200 + data, vs a cached response from a
> conditional GET that resulted in a 304 (vs for the record a request that was
> serviced entirely from HTTP cache (no HTTP requests at all) based on the
> presence of an appropriate Cache-Control response header in a previous
> response).

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.

Thanks for taking the time to answer my naive questions.

Tom