<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 5/3/18 12:06 PM, Tom Scavo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEtu=dMEy3Ewy1PNfjYKAAUhHKHRJ+C213rJkFuM3e+uPCeo-w@mail.gmail.com">
<pre wrap="">On Thu, May 3, 2018 at 11:50 AM, Cantor, Scott <a class="moz-txt-link-rfc2396E" href="mailto:cantor.2@osu.edu"><cantor.2@osu.edu></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
I'm confused. We know that a FileBackedHTTPMetadataProvider does HTTP
caching by default (although I don't know the details).</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAEtu=dMEy3Ewy1PNfjYKAAUhHKHRJ+C213rJkFuM3e+uPCeo-w@mail.gmail.com">
<pre wrap=""> Are you saying
that the HTTP cache attributes (httpCaching, httpCacheDirectory,
httpMaxCacheEntries, httpMaxCacheEntrySize) may be used to override
the default HTTP cache behavior?</pre>
</blockquote>
<br>
Well, yes, for the (internally constructed, non-httpClientRef)
HttpClient response caching. That being the whole point of those
attributes...<br>
<br>
<blockquote type="cite"
cite="mid:CAEtu=dMEy3Ewy1PNfjYKAAUhHKHRJ+C213rJkFuM3e+uPCeo-w@mail.gmail.com">
<pre wrap="">If so, the default shown in the doc
("none") is incorrect.</pre>
</blockquote>
<br>
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.<br>
</body>
</html>