reconciling the Reloading Attributes with the Dynamic Attributes

[Tom Scavo]

On Tue, May 8, 2018 at 12:54 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> 1) What is the effect of the metadata's @cacheDuration attribute on the
>> operation of a reloading provider (such as the
>> FileBackedHTTPMetadataProvider)?
>
> It sets bounds on the refresh timer's behavior, I believe, so it can trigger earlier refresh attempts if it's small, within the bounds of the min/max settings. It's a signal to try for new data more often, which seems logical to me.

Thanks, that makes sense. Is the same true in the case of a dynamic
provider? If so, why are the attributes called
minRefreshDelay/maxRefreshDelay in the one case and
minCacheDuration/maxCacheDuration in the other?

Btw, note that the refreshDelayFactor attribute has exactly the same
description in both cases. That description really only makes sense
for a reloading provider. In the case of a dynamic provider, the
description is very confusing.

I'm guessing the reason for these inconsistencies is purely
historical. If so, now is a good time to rationalize the attribute
names (since deprecated features are being rooted out as we speak).

>> The answer to the first question would appear to be "none" since a
>> FileBackedHTTPMetadataProvider is a non-caching metadata provider. Is this
>> correct?.
>
> I don't think so.

I believe you. The point I'm trying to make is that httpCaching="none"
in the case of FileBackedHTTPMetadataProvider is an apparent
contradiction.

>> The answer to the second question depends on the value of the
>> requireValidMetadata attribute but why then is the
>> expirationWarningThreshold attribute confined to the reloading attributes?
>
> It does not depend on that and I don't know anything about the other attribute, so I can't say.

The requireValidMetadata attribute is a Common Attribute so it should
apply to a dynamic provider, in which case the
expirationWarningThreshold attribute (which itself is misnamed [1])
should also apply. That seems like a bug.

Tom

[1] https://issues.shibboleth.net/jira/browse/OSJ-236