Configuring a file-backed HTTP resource for attribute filters

[Brent Putman]

On 7/21/15 4:37 PM, Wessel, Keith wrote:
>
>  
>
> I see that it is empty after shutdown, and after start-up the files
> are pulled down and stored.
>

Ok, that's all good then.

> So, the 304 message I was seeing in the webserver log from the server
> hosting the attribute filter files must have been a subsequent fetch,
> though I didn’t see that in the logs.
>

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.

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



> I can look again. At any rate, I’m getting valid files in the cache
> dir; they’re just not getting created in the IDP conf dir.
>
>  
>

By "in the IDP conf dir" do you mean the backing file?  Re: the cache
dir: did you actually confirm that it is caching the attribute filter
file(s) in question?  Despite their horrendous names, those should just
be XML files, so you can inspect them.



> And yes, when I mentioned manually pulling them down, I meant wgetting
> the files and dropping them in place where the IDP would store them in
> the conf dir before starting the IDP. Interestingly when I do this
> then start the IDP, it does update these files, or at least update
> their timestamps. I did this before noon and left the IDP running, and
> the attribute filter files in the conf dir were having their
> timestamps updated every 15 minutes as appropriate.
>
>  
>

Well, I don't have an explanation.  That doesn't really make sense then.


> So, with all this said, which of the classes do you want me to provide
> debug-level logging for in Gira?
>


At a minimum:

net.shibboleth.ext.spring.resource.HTTPResource
net.shibboleth.ext.spring.resource.FileBackedHTTPResource
org.apache.http

Depending on whether this is prod or not and you are concerned about
logging I/O, you could put the sub-package org.apache.http.wire down to
WARN.  Although if you can leave at DEBUG might be helpful in showing
exactly what it's doing interacting with the web server.

Also if you can provide to us the actual URL you're hitting, seeing the
live response headers it sends back might be informative.  You can send
off-list if you want to me, Scott, Rod, etc.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150721/c9cd5cda/attachment-0001.html>