Dynamic metadata resolver; HttpClient usage

[Rod Widdowson]

> I think this was actually one reason for Chad's HttpClient builders in
> java-support.  He was probably thinking that those build in reasonable
> defaults for our own component purposes (e.g. Ian's Jira issue about
> timeouts).  Then in components you don't have to do any defaulting per
> se.  If you want different, you wire in an explicit bean.  Note that we
> do have builders for both in-memory and file caching HttpClients.

Ah yes, I remember that now.  Thanks for reminding me.  I suppose the
question then becomes as to whether we configure these sensible defaults to
use the caching provider.  Or jettison them entirely in favour of
property-driven with decent defaults in native Spring XML (my preferred
solution)
 
>> "%{idp.httpclient.dynamicmetadata}:shibboleth.httpclient.caching}".
> 
> That sounds like a tenable idea.  I was thinking of this notion for
> *all* things that use HttpClient, not just the dynamic metadata
> resolver, so I'd probably pick a different property name though.

Right so idp.httpclient.service resource and so on
 

> In general, one of my main reasons for bringing this up is that we've
> been adopting the strategy that conditional GETs etc, is delegated to
> the HttpClient layer, and our components stay ignorant of it.   I still
> think that's the right design choice.  

Me too - while noting that the HTTPMetadataProvider does understand
condition gets and I think that this is correct as well (because we need the
control and the datasize is huge).

The DynamicMetadataProvider is the one which makes it really important
because it feels like it will (eventually) more mainstream than http
configuration (outside those federations which supply bundled configuration
and who can be trusted to ensure that the caching is enabled.

R