| Note | ||
|---|---|---|
| ||
As of V3.4, the |
...
A typical use of FileBackedHTTPMetadataProvider is to load (and periodically reload) a metadata aggregate from a remote source via HTTP:
| Include Page | ||||
|---|---|---|---|---|
|
Frequently Asked Questions
See also Troubleshooting.
What triggers the metadata refresh process?
A FileBackedHTTPMetadataProvider loads (and reloads) metadata in the background, independent of normal IdP operation. The frequency of metadata refresh is influenced by the Reloading Attributes. In particular, the minRefreshDelay and maxRefreshDelay attributes strongly influence the frequency of metadata refresh. Any cacheDuration and validUntil attributes in the metadata itself also influence the process.
...
There are at least two things you can do to help minimize the impact of the metadata refresh process: 1) install and configure adequate memory on your system, and 2) customize the frequency of metadata refresh for optimal performance. In any case, the FileBackedHTTPMetadataProvider implementation has two features that positively affect metadata refresh: background processing and HTTP conditional GET. Neither of these features is configurable, however, so there is nothing further you need to do beyond the two items mentioned above.
Anchor HTTPConditionalGET HTTPConditionalGET
What is HTTP conditional GET?
| HTTPConditionalGET | |
| HTTPConditionalGET |
A conforming server will respond to an HTTP conditional GET request (RFC 7232) with a 304 (Not Modified) status code if the target resource has not changed since the last time it was requested. Note that a 304 response does not include a response body, which is more efficient than the corresponding 200 response (especially for large metadata files). More importantly, due to the manner in which the FileBackedHTTPMetadataProvider is implemented, the IdP can safely ignore a 304 response, which precludes the need to redundantly process the metadata. For large signed metadata files, the savings can be quite significant.
...
The backing file is only used at startup. If the remote server is unavailable at startup, the backing file is loaded instead and all the configured filters are run on the backing file. If a single filter fails, the backing file is not loaded. For example, if the provider contains a SignatureValidationFilter but the signature on the backing file can not be verified, the entire load operation fails.
...