HTTP Client Attributes

[Brent Putman]

On 5/3/18 12:33 PM, Tom Scavo wrote:
> On Thu, May 3, 2018 at 12:15 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>> 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.
> Okay, I understand now.
>
>>  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.
> Unless I'm missing something, the documentation says nothing about the
> default caching behavior of the HTTP metadata providers. Until just
> now, I thought the HTTP cache attributes (httpCaching,
> httpCacheDirectory, httpMaxCacheEntries, httpMaxCacheEntrySize)
> completely controlled the caching behavior.
They do, for *HTTP* caching.  That's literally what they are.  The
providers don't do "real" *HTTP* caching themselves. They store and use
the ETag and Last-Modified for conditional GETs, that's all. 

>
> Are the HTTP cache attributes mutually exclusive of httpClientRef?

Yes, b/c like the other mutually exclusive things, the caching behavior
is part of the config of the HttpClient instance.  If you use the
internally-constructed one (no httpClientRef), those are used.  If you
inject one (with httpClientRef), then any/all of those things are
configured on the injected instance, not on the metadata provider.