Configuring a file-backed HTTP resource for attribute filters

[Wessel, Keith]

That's what I thought! Not modified since when? But that's what I'm getting... and that's apparently why the IDP was reporting the file was "inaccessible."

So are you saying I should file this as a bug? For me to get a 304, I'd have to be doing a conditional get, and that makes no sense if the file hasn't been downloaded yet.

Keith


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

On 7/21/15, 11:54 AM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>I'm not sure if this is the same as the bug you referenced, Rod, but I looked at the web server logs on the system serving the attribute filter defitions, and it has a response code of 304 (not modified). I could, of course, prime the pump by manually fetching the file before IDP start-up. My question is should I need to do this, or is this a bug?

I don't think you can get a 304 on the first fetch, it doesn't have any cache information to send the server yet.

-- Scott

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