Shibboleth FileBackedHTTPMetadataProvider

[Cantor, Scott]

On 3/30/16, 5:19 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:


>
>Sorry that I did not get to this thread sooner, I was otherwise occupied.  I was/am unclear whether Scott's and Rod's comments are about the SP or the IDP or both.  But based on the other longish note I just sent, what you put in the IDP30 space is incorrect. The backing file is not only used at startup.  It's used anytime the HTTP GET fails.  The code that consumes the output of the fetchMetadat() operation does not know from where the data came, it's completely transparent to the caller.

I guess I didn't think it through, but you can see the oddness: if you're running happily for a week, and then things fail, the backup copy can't be any newer than the version you're running with. I guess I didn't realize it just loaded it anyway, but the SP might also, I'd have to check the code. You can see that it's kind of wasted effort. It may be doing that for consistency, because as you said, the code is horrendous in both.

>The idea of at startup time loading first from the backing file, for efficiency, and then letting the regular refresh process kick off to do HTTP fetch is an interesting one.  I would have to look and see whether that is easy or hard.  The code is already very
> complicated, and special casing the startup would be at best need to be carefully done.  It might also require some API additions or changes to accomplish.

Same. I think it's interesting, but not worth breaking everything for. It's more interesting to the SP anyway, since they tend to restart more than IdPs, and IdPs should be running in an HA fashion anyway.

-- Scott