HTTP Client Attributes

[Tom Scavo]

Hmm, I thought I understood but maybe not. Please be patient with me
as I probe further. I really do want to know how this works.

On Thu, May 3, 2018 at 2:25 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>
> On 5/3/18 2:10 PM, Tom Scavo wrote:
>
> On Thu, May 3, 2018 at 2:05 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>
> What happens if httpCaching is set to "none" on DynamicHTTPMetadataProvider?
>
> There will be no HTTP caching, so when it doesn't have a non-expired
> EntityDescriptor in memory for an entityID, it will always issue an HTTP
> request.

And that request will be an HTTP conditional request, right? If the
response comes back 304, I assume it uses the EntityDescriptor in
memory. The downside is, when httpCaching="none", it always goes out
to the network.

OTOH, if httpCaching="memory", it tries to use the EntityDescriptor
cached in memory without issuing a request. (Same with
httpCaching="file", I suppose.) If the cached file becomes
cache-invalid, an HTTP conditional request is issued. Regardless of
the response (200 or 304), the cache is refreshed.

For FileBackedHTTPMetadataProvider, the default is httpCaching="none",
so again it always goes out to the network. If you configure
httpCaching="file", it goes to cache first, but since
FileBackedHTTPMetadataProvider has no cacheDuration settings, file
caching serves no purpose unless the metadata itself has a
cacheDuration XML attribute. In any case, make sure
httpMaxCacheEntrySize is large enough to accommodate the file (which
can be quite large).

For FileBackedHTTPMetadataProvider, I don't see a use for
httpCaching="memory", except perhaps for individual entity
descriptors. Which reminds me, is there a way to batch load a bunch of
individual entity descriptors? The use case is pre-loading of
high-value entities.

Thanks,

Tom