Shibboleth FileBackedHTTPMetadataProvider

[Brent Putman]

On 3/30/16 5:27 PM, Cantor, Scott wrote:
> 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:
>
>
> 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.

Yes, I think I see that now.  By definition the bytes on disk are
(usually) the same as the processed metadata you have cached.  Could be
older if there was an error writing the file, but not newer.  (Assuming
someone doesn't do something odd like manually update the backing file
out-of-process. I vaguely recall someone mentioning doing something
like that long ago.  But we can just say "not supported".)

>  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.

Agreed, it does seem inefficient. 



>  It may be doing that for consistency, because as you said, the code is horrendous in both.

I was just looking at it.  To special-case it just for *startup* might
be hard per se, but I think that's not really what you technically
want.  Probably want to only read the backing file if there is no
cached metadata in the resolver.  I think that's a purer statement of
the requirement.  And that is I think easier (although I think I just
spotted a minor non-operational bug that would need to be fixed
first).  I'll open an issue to look at further.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160330/209c2afc/attachment.html>