<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 7/21/15 12:26 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:AE70167A-8A88-40F4-887F-56A7A70E6D38@osu.edu"
type="cite">
<pre wrap="">On 7/21/15, 12:19 PM, "users on behalf of Wessel, Keith" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofkwessel@illinois.edu"><users-bounces@shibboleth.net on behalf of kwessel@illinois.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I don't see how that's possible at all, but if that's what you're getting...
</pre>
</blockquote>
<br>
<br>
Well, I haven't been following all the details of this thread, but I
think you could get this if you are using a filesystem caching
variant of the HttpClient. There I think the cached data will
persist across restarts, so indeed the first fetch after an IdP
restart could be doing a conditional GET, if the resource had been
fetched and cached previously. Which HttpClient bean are you using
here?<br>
<br>
<br>
<br>
<blockquote cite="mid:AE70167A-8A88-40F4-887F-56A7A70E6D38@osu.edu"
type="cite">
<pre wrap="">
The Apache HTTP client blows. As bad as OpenSSL is, that's how good libcurl is. Wish there was a Java version. I literally have not touched the core HTTP client code in the SP in like a decade.
</pre>
</blockquote>
<br>
<br>
I haven't gotten to that conclusion yet. I use it for other things
and don't have problems. And still not convinced that the issues
some people see are attributable to the HttpClient code.<br>
</body>
</html>