HTTP Client Attributes

[Brent Putman]

On 5/3/18 12:06 PM, Tom Scavo wrote:
> On Thu, May 3, 2018 at 11:50 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>> It is 'none', if one is using the default internally-constructed HttpClient.
>>> Because of the 1) memory requirements of in-memory and 2) disk
>>> requirements of disk, we didn't want to make assumptions about either of
>>> those defaults being ok.
>> And because they do their own caching, I believe. I think there was internal logic already to remember a cache tag and use it, just not across restarts (whereas the SP actually stores the cache tags on disk, I think). We didn't need the HttpClient's support for the batch case.
> I'm confused. We know that a FileBackedHTTPMetadataProvider does HTTP
> caching by default (although I don't know the details).

As I said just now in another note, they don't do HTTP caching in the
sense you mean.  Internally the HTTP metadata providers cache ETag and
Last-Modified to do conditional GETs.  That's all.


>  Are you saying
> that the HTTP cache attributes (httpCaching, httpCacheDirectory,
> httpMaxCacheEntries, httpMaxCacheEntrySize) may be used to override
> the default HTTP cache behavior?

Well, yes, for the (internally constructed, non-httpClientRef)
HttpClient response caching.  That being the whole point of those
attributes...

> If so, the default shown in the doc
> ("none") is incorrect.

Um, how do the presence of attributes which allow overriding the
default negate the meaning of the default?  For the FileBacked- batch
one, It is 'none', I assure you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20180503/b9c5ec50/attachment.html>