HTTP Client Attributes

[Tom Scavo]

On Mon, May 7, 2018 at 5:13 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> Every single time it gets that 304, the Apache HttpClient returns the cached response body to the IdP internally, at which point it parses that XML and verifies the signature and does absolutely everything it did the first time. There is zero optimization other than skipping transmission of a small amount of data across the network.

Okay, I think I understand how it works now.

> The batch plugins do their own HTTP caching and issue their own conditional GET, allowing them to detect the 304 result and skip all the processing they would have done. This saves both the gigantic network overhead and the massive parsing and signature cost.
>
> The dynamic plugins do NOT do this.

Why not? Clearly if the batch providers can do this, then the dynamic
providers can as well. Why not be consistent (and optimal)?

> They ask the HTTP client for a response, and the client internally says "here it is" or "error". There is no 304 notion. That's internal to the client and is never seen by the plugin so it has no chance to bypass any of its work. Every single "fetch" results in a totally new load of metadata regardless of whether it actually changed. This is only tolerable because the number of fetches is limited by the internal metadata cacheDuration and the plugin settings.

Yup, I get it, thanks for explaining this to me.

>> I guess you're referring to the cache duration timeouts, in which case I totally
>> agree.
>
> No, I am not referring to anything to do with caching. I mean timeouts, period. Socket, connection, response. Network timeouts.

Ah, in that case there's more to talk about but I'll save that
discussion for another day.

Tom