Configuring a file-backed HTTP resource for attribute filters

[Wessel, Keith]

Yes, there's a 200 and a 304. Sorry for that confusion, it was all a red herring.

By the IDP conf dir, yes, I mean the backing file. If I wget the file before IDP start-up, it gets updated properly (both contents and timestamp) every 15 minutes. And yes, obviously, that would also mean that the files in the cache dir are valid and correct in terms of content.

So, it seems that the backing file can get updated, but if it doesn't exist on IDP start-up, it can't get created.

I'll turn up the logging as instructed and send in a GIRA ticket. And Rod, since you asked first, I'll send you the attribute filter file URL off-list.

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, July 21, 2015 4:02 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Configuring a file-backed HTTP resource for attribute filters

On 7/21/15, 4:56 PM, "users on behalf of Brent Putman" <users-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

>Ah.  I didn't understand that the 304 you were reporting was from the *web server*.  Not sure anyone else did either.  That is what is expected then.   You should see 1 GET returning a 200, and then more additional GETs returning 304s.  That's normal.

What I assumed from the original message was that *all* he saw was a 304. That's the part I was struggling with until I then assumed the file-based cache was maintained across restarts, but now that apparently isn't true either, so I'm back to confused unless in fact there's both a 200 and a 304.

>In addition to the exists() method I earlier mentioned, there are other methods in HTTPResource which invoke fetches, so those would all result potentially in conditional GETS (what the HttpClient caching subsystem will report as "VALIDATED").

But clearly for a 304 you have to have a primed cache to start with.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net