<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Well, now, this generated quite a bit of discussion. That’ll teach me to choose my time more carefully for when I go to lunch.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Where shall we start? First, this file cache you referred to. That’s an in-memory cache? Something that gets cleaned out by a restart? ‘Cause this error occurs
on jetty/IDP start-up. So, if it’s in-memory, I should be starting with a clean cache and without the local backin file existing. BTW, when I do suck downthe file manually before starting the IDP, the warnings go away and the IDP happily accepts the 304 return
code.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Shall I try turning up logging as Brent suggested and see what that tells me? And perhaps, if there’s nothing obvious in the output, put that output in Gira?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Keith<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> users [mailto:users-bounces@shibboleth.net]
<b>On Behalf Of </b>Brent Putman<br>
<b>Sent:</b> Tuesday, July 21, 2015 12:09 PM<br>
<b>To:</b> users@shibboleth.net<br>
<b>Subject:</b> Re: Configuring a file-backed HTTP resource for attribute filters<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 7/21/15 12:51 PM, Cantor, Scott wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre><o:p> </o:p></pre>
<pre>Ok, admittedly I interpreted "no backup file yet" as equivalent to the file cache not being populated either, which aren't necessarily equivalent. So that is the first question to ask, and one can always flush that directory.<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Looking at the code, the backup file referenced is definitely ours. The root issue happens before that, something is going wrong with the FileBacked- class call to super.getInputStream() (the regular HttpResource).<br>
<br>
What would be very informative is to see:<br>
<br>
1) the DEBUG output from net.shibboleth.ext.spring.resource.HTTPResource. That will report what the caching status of the file as reported by HttpClient.<br>
<br>
2) the ERROR level output reporting exactly what HTTP status code was effectively returned from the client call. My previous testing and understanding what that if the HttpClient served the response from cache, then you get back a 200, but perhaps that's not
always the case. The superclass getInputStream() has the code block:<br>
<br>
<tt><span style="font-size:10.0pt"> if (httpStatusCode != HttpStatus.SC_OK) {</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt> String errMsg =</tt><br>
<tt> "Non-ok status code " + httpStatusCode + " returned from remote resource " + resourceURL;</tt><br>
<tt> log.error(errMsg);</tt><br>
<tt> throw new IOException(errMsg);</tt><br>
<tt> }</tt></span><br>
<br>
I'd like to confirm that that is what's happening to throw the IOException caught by the FileBacked- subclass, and what the exact code is. Perhaps we are misusing the HttpClient there, i.e. maybe codes other than SC_OK should be treated as success. Just guessing.
Or maybe there really is a bug in HttpClient somewhere.<br>
<br>
Also interesting would be DEBUG output from org.apache.http. (Warning: that will be a lot, since org.apache.http.wire does a wire level dump of all the traffic).<br>
<br>
Another thing to look at might be the max cache entry size: We have for the FileCachingHttpClient default of:<br>
<br>
<tt><span style="font-size:10.0pt">p:maxCacheEntrySize="%{idp.httpclient.filecaching.maxCacheEntrySize:10485760}</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
</span>so 10MB. Could the resource being fetched here be bigger than that? I have thought that if the resource is bigger, it simply isn't cached, but perhaps it's more complicated and/or there is a bug around that (ours or theirs).<br>
<br>
Finally, might be informative to see if instead switching to the shibboleth.MemoryCachingHttpClient resolves the issue. Might hint where the problem is.<o:p></o:p></p>
</div>
</body>
</html>