Configuring a file-backed HTTP resource for attribute filters

Brent Putman putmanb at georgetown.edu
Tue Jul 21 12:35:26 EDT 2015



On 7/21/15 12:26 PM, Cantor, Scott wrote:
> On 7/21/15, 12:19 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>
>> 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.
> I don't see how that's possible at all, but if that's what you're getting...


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?



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


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150721/7f981074/attachment-0001.html>


More information about the users mailing list