<style>
/* Changing the layout to use less space for mobiles */
@media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) {
#email-body { min-width: 30em !important; }
#email-page { padding: 8px !important; }
#email-banner { padding: 8px 8px 0 8px !important; }
#email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; }
#email-fields { padding: 0 8px 8px 8px !important; }
#email-gutter { width: 0 !important; }
}
</style>
<div id="email-body">
<table id="email-wrap" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f0f0f0;color:#000000;width:100%;">
<tr valign="top">
<td id="email-page" style="padding:16px !important;">
<table align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;border:1px solid #bbbbbb;color:#000000;width:100%;">
<tr valign="top">
<td bgcolor="#ffffff" style="background-color:#ffffff;color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;line-height:1;"><img src="https://shibboleth.net/images/shib_240x83.png" alt="" style="vertical-align:top;" /></td>
</tr><tr valign="top">
<td id="email-banner" style="padding:32px 32px 0 32px;">
<table align="left" border="0" cellpadding="0" cellspacing="0" width="100%" style="width:100%;">
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;padding:0;">
<img id="email-avatar" src="https://issues.shibboleth.net/jira/secure/useravatar?avatarId=10202" alt="" height="48" width="48" border="0" align="left" style="padding:0;margin: 0 16px 16px 0;" />
<div id="email-action" style="padding: 0 0 8px 0;font-size:12px;line-height:18px;">
<a class="user-hover" rel="putmanb@shibboleth.net" id="email_putmanb@shibboleth.net" href="https://issues.shibboleth.net/jira/secure/ViewProfile.jspa?name=putmanb%40shibboleth.net" style="color:#326ca6;">Brent Putman</a>
commented on <img src="https://issues.shibboleth.net/jira/images/icons/issuetypes/task.png" height="16" width="16" border="0" align="absmiddle" alt="Task"> <a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/IDP-538'>IDP-538</a>
</div>
<div id="email-summary" style="font-size:16px;line-height:20px;padding:2px 0 16px 0;">
<a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/IDP-538'><strong>Use caching HttpClient by default</strong></a>
</div>
</td>
</tr>
</table>
</td>
</tr>
<tr valign="top">
<td id="email-fields" style="padding:0 32px 32px 32px;">
<table border="0" cellpadding="0" cellspacing="0" style="padding:0;text-align:left;width:100%;" width="100%">
<tr valign="top">
<td id="email-gutter" style="width:64px;white-space:nowrap;"></td>
<td>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr valign="top">
<td colspan="2" style="color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;padding:0 0 16px 0;width:100%;">
<div class="comment-block" style="background-color:#edf5ff;border:1px solid #dddddd;color:#000000;padding:12px;"><p>So that's an interesting question. In the batch HTTPMetadataResolver, the one where we're likely to see the large files, we keep (and have always kept) the ETag and Last-Modified headers around and do a conditional GET with those. That's in large part because we have to be able to satisfy the contract of the superclass' fetchMetadata(), which must return null if the metadata hasn't changed since the last retrieval. So really, we perhaps don't technically need the caching client there, as far as I can see. We already essentially do caching of the body (the metadata) and we're doing conditional GETs. </p>
<p>Because we assumed the use of a caching client, we don't do anything like that currently in the newer stuff: the dynamic HTTP metadata resolver and HTTPResource. Those are typically going to be much smaller response bodies, I'd think. (Although I guess we can't know for sure about the HTTPResource targets.)</p>
<p>So I suppose we could just: 1) use an in-memory caching client on those, since the memory overhead might be much smaller 2) just punt and store ETag/Last-Modified and do conditional GETs as well.</p>
<p>I don't know all the issues we'd run into with #2, but I think for the resource the big one is: we don't currently cache the body, etc. It's just not the model of the Spring Resource API. I think that was what drove us to think about the caching client in the first place, IIRC. For the dynamic metadata provider, it off-hand seems do-able, but there might be some API and refactoring issues.</p></div>
<div style="color:#505050;padding:4px 0 0 0;"> </div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td><!-- End #email-page -->
</tr>
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:10px;line-height:14px;padding: 0 16px 16px 16px;text-align:center;">
This message is automatically generated by JIRA.<br />
If you think it was sent incorrectly, please contact your JIRA administrators<br />
For more information on JIRA, see: <a style='color:#326ca6;' href='http://www.atlassian.com/software/jira'>http://www.atlassian.com/software/jira</a>
</td>
</tr>
</table><!-- End #email-wrap -->
</div><!-- End #email-body -->