HTTP Client Attributes

[Tom Scavo]

On Mon, May 7, 2018 at 3:19 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> I'm at a stopping point so now is a good time to review, comment and/or
>> edit. In particular, on the DynamicHTTPMetadataProvider page, there's this:
>> "For optimal performance, configure a custom HTTP client that [performs
>> HTTP conditional GET]." I don't know how to do that so perhaps someone
>> else can pencil that in.
>
> I don't think it's true.

Okay, you can change it, or you can explain it to me and I'll be happy
to change it. Whatever works best.

> A simple fetch of a small bit of XML every so often doesn't really benefit from that much, and the code on top just does all the same work either way. The real work is parsing it, verifying a signature, and all that happens blindly.

>From [RFC7232]: “Conditional GET requests are the most efficient
mechanism for HTTP cache updates [RFC7234].”

I may be missing something but HTTP conditional GET provides the
"optimal performance" I refer to in the wiki. When the cached response
becomes invalid (after the cache duration settings expire), the client
sends a conditional GET request. If the response is 200, the new
response is parsed and the signature is verified, just like you say.
If the response is 304, none of that needs to happen, however, and so
the previously cached response becomes valid once again. At this point
the cache duration settings reassert control.

As a specific example, suppose you have a resource that is normally
updated daily on the server side. Let the cache duration be 4 hrs. Now
the client initially fetches the resource and commits it to the cache.
The next 4 hrs are free (no HTTP requests). At the end of 4 hrs, the
cached resource becomes invalid. The very next time it's needed by the
IdP, the client sends a conditional GET request to the server. If
we're still within the 24 hr period, the response will be 304 and so
the client marks the cached resource as valid, at which point the next
4 hrs are free. The rest of the life cycle should be clear.

> That's the cost of *not* being HTTP aware, which is the difference between the dynamic and aggregate plugins.

I don't know what that means.

> The important settings are around timeouts.

I guess you're referring to the cache duration timeouts, in which case
I totally agree.

Tom