HTTP Client Attributes

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

HTTP Client Attributes

Tom Scavo
I'm trying to reconcile the attributes on
FileBackedHTTPMetadataProvider [1] and DynamicHTTPMetadataProvider.
[2] The following attributes are common to both metadata providers:

disregardTLSCertificate
connectionRequestTimeout
requestTimeout (DEPRECATED)
connectionTimeout
socketTimeout
proxyHost
proxyPort
proxyUser
proxyPassword
basicAuthUser
basicAuthPassword
httpCaching
httpCacheDirectory
httpMaxCacheEntries
httpMaxCacheEntrySize
httpClientRef (all of the above are incompatible w/ httpClientRef)
httpClientSecurityParametersRef
tlsTrustEngineRef

OTOH, the following attributes are absent from
FileBackedHTTPMetadataProvider but present on
DynamicHTTPMetadataProvider:

supportedContentTypes
disregardSslCertificate (DEPRECATED)
maxConnectionsTotal
maxConnectionsPerRoute

That seems to be an oversight. Can someone confirm the following?

1. The latter four attributes apply to FileBackedHTTPMetadataProvider as well.

2. The latter three attributes are incompatible with httpClientRef.

3. The supportedContentTypes attribute is independent of httpClientRef.

Thanks,

Tom

[1] https://wiki.shibboleth.net/confluence/x/kQInAQ
[2] https://wiki.shibboleth.net/confluence/x/o4AgAQ
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: HTTP Client Attributes

Rod Widdowson
> OTOH, the following attributes are absent from
> FileBackedHTTPMetadataProvider but present on
> DynamicHTTPMetadataProvider:
>
> supportedContentTypes
> disregardSslCertificate (DEPRECATED)
> maxConnectionsTotal
> maxConnectionsPerRoute
>
> That seems to be an oversight. Can someone confirm the following?
>
> 1. The latter four attributes apply to FileBackedHTTPMetadataProvider as well.

From the schema:
        supportedContentTypes,
        maxConnectionsTotal,
        maxConnectionsTotal
                are *NOT* available (directly) on the batch loaders.  
        disregardSslCertificate
                is deprecated and its status is irrelevant.
 
> 2. The latter three attributes are incompatible with httpClientRef.

From the code:  The following attributes cause a warning to be emitted if present with a httpClientRef

        requestTimeout
        connectionTimeout
        connectionRequestTimeout
        socketTimeout
        disregardSslCertificate
        disregardTLSCertificate
        proxyHost
        proxyPort
        proxyUser
        proxyPassword

> 3. The supportedContentTypes attribute is independent of httpClientRef.

Entirely.  The content type is checked after the client has been used to get the response.

HTH

/Rod

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
Thanks Rod. Comments and questions below.

On Thu, May 3, 2018 at 11:11 AM, Rod Widdowson <[hidden email]> wrote:
>
> From the schema:
>         supportedContentTypes,
>         maxConnectionsTotal,
>         maxConnectionsTotal
>                 are *NOT* available (directly) on the batch loaders.

That seems like a bug. Should I file an issue in jira?

> From the code:  The following attributes cause a warning to be emitted if present with a httpClientRef
>
>         requestTimeout
>         connectionTimeout
>         connectionRequestTimeout
>         socketTimeout
>         disregardSslCertificate
>         disregardTLSCertificate
>         proxyHost
>         proxyPort
>         proxyUser
>         proxyPassword

Hmm, the wiki docs do not agree with the above list so let me ask: Are
basicAuthUser and basicAuthPassword mutually exclusive of
httpClientRef? Are httpClientRef and httpClientSecurityParametersRef
mutually exclusive of each other?

Here is the Million Dollar Question: What is the default value of the
httpCaching attribute on a FileBackedHTTPMetadataProvider? (Please
don’t say “none!”)

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman



On 5/3/18 11:24 AM, Tom Scavo wrote:
Thanks Rod. Comments and questions below.

On Thu, May 3, 2018 at 11:11 AM, Rod Widdowson [hidden email] wrote:
From the schema:
        supportedContentTypes,
        maxConnectionsTotal,
        maxConnectionsTotal
                are *NOT* available (directly) on the batch loaders.
That seems like a bug. Should I file an issue in jira?
No.  The maxConnections* ones are not relevant to t he batch HTTP providers, since they only ever execute 1 HTTP connection at a time, to the domain they are configured with.  The dynamic provider can have many simultaneous connections, to many different mains (routes).

The supportedContentTypes option is simply not supported by the (older) batch resolvers.

Hmm, the wiki docs do not agree with the above list so let me ask: Are
basicAuthUser and basicAuthPassword mutually exclusive of
httpClientRef? Are httpClientRef and httpClientSecurityParametersRef
mutually exclusive of each other?

Off-hand I don't remember for sure. I'd have to look.  I didn't think they were.




Here is the Million Dollar Question: What is the default value of the
httpCaching attribute on a FileBackedHTTPMetadataProvider? (Please
don’t say “none!”)

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.


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: HTTP Client Attributes

Cantor, Scott E.
> 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.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
In reply to this post by Brent Putman
On Thu, May 3, 2018 at 11:44 AM, Brent Putman <[hidden email]> wrote:

>
> On 5/3/18 11:24 AM, Tom Scavo wrote:
>
> On Thu, May 3, 2018 at 11:11 AM, Rod Widdowson <[hidden email]>
> wrote:
>
> From the schema:
>         supportedContentTypes,
>         maxConnectionsTotal,
>         maxConnectionsTotal
>                 are *NOT* available (directly) on the batch loaders.
>
> That seems like a bug. Should I file an issue in jira?
>
> No.  The maxConnections* ones are not relevant to t he batch HTTP providers,
> since they only ever execute 1 HTTP connection at a time, to the domain they
> are configured with.  The dynamic provider can have many simultaneous
> connections, to many different mains (routes).

Okay, I see. Are the maxConnections* attributes mutually exclusive of
the httpClientRef attribute?

> The supportedContentTypes option is simply not supported by the (older)
> batch resolvers.

For historical reasons, not technical reasons, I presume.

> Hmm, the wiki docs do not agree with the above list so let me ask: Are
> basicAuthUser and basicAuthPassword mutually exclusive of
> httpClientRef? Are httpClientRef and httpClientSecurityParametersRef
> mutually exclusive of each other?
>
> Off-hand I don't remember for sure. I'd have to look.  I didn't think they
> were.

Thanks Brent.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman



On 5/3/18 11:56 AM, Tom Scavo wrote:
On Thu, May 3, 2018 at 11:44 AM, Brent Putman [hidden email] wrote:

 Are the maxConnections* attributes mutually exclusive of
the httpClientRef attribute?

Yes.


      
The supportedContentTypes option is simply not supported by the (older)
batch resolvers.
For historical reasons, not technical reasons, I presume.

Mostly, although off-hand I'm not sure they totally make sense for the batch ones.  It's there for dynamic b/c that whole approach is/was more of a moving target with respect to technical specs.  That property is declared on an abstract base class, so it's more open-ended than batch.  The batch ones probably less so.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
In reply to this post by Cantor, Scott E.
On Thu, May 3, 2018 at 11:50 AM, Cantor, Scott <[hidden email]> 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). Are you saying
that the HTTP cache attributes (httpCaching, httpCacheDirectory,
httpMaxCacheEntries, httpMaxCacheEntrySize) may be used to override
the default HTTP cache behavior? If so, the default shown in the doc
("none") is incorrect.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman
In reply to this post by Cantor, Scott E.



On 5/3/18 11:50 AM, Cantor, Scott 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

That's true, the HTTP batch ones cache ETag and Last-Modified, so they can do conditional GETs.  They don't however cache the actual response data, so it's a little different than HttpClient "native" memory or disk caching.

We didn't need the HttpClient's support for the batch case.
Yes.  It probably also makes less sense to do for batch since the files are very large and you probably on average request/refresh them less often than you would with dynamic, where you have lots of smaller files that you might want to (re)fetch more frequently.  But it's an option if people want it.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman
In reply to this post by Tom Scavo



On 5/3/18 12:06 PM, Tom Scavo wrote:
On Thu, May 3, 2018 at 11:50 AM, Cantor, Scott [hidden email] 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.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
On Thu, May 3, 2018 at 12:15 PM, Brent Putman <[hidden email]> wrote:

>
> On 5/3/18 12:06 PM, Tom Scavo wrote:
>
> On Thu, May 3, 2018 at 11:50 AM, Cantor, Scott <[hidden email]> 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.

Are the HTTP cache attributes mutually exclusive of httpClientRef?

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
>> On 5/3/18 12:06 PM, Tom Scavo wrote:
>>
>> On Thu, May 3, 2018 at 11:50 AM, Cantor, Scott <[hidden email]> 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.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
On Thu, May 3, 2018 at 12:55 PM, Brent Putman <[hidden email]> wrote:

>
> On 5/3/18 12:33 PM, Tom Scavo wrote:
>>
>> 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.

Caching the HTTP response headers is "HTTP caching" by my definition.
In any case, to avoid further confusion, we should clarify the docs. I
will do that eventually if you don't beat me to it.

Based on everything I've read and heard so far, here is what I think
is going on:

- By default, the HTTP metadata providers perform HTTP conditional GET
but they do not cache the response body, and moreover, the cached HTTP
headers do not survive a restart.

- To cache the full HTTP response (including the response body) set
the httpCaching attribute to either “file” or “memory”.

- The full HTTP response will survive a restart if (and only if)
httpCaching=”file”.

Please correct me if I'm still off base.

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman



On 5/3/18 1:46 PM, Tom Scavo wrote:

Based on everything I've read and heard so far, here is what I think
is going on:

- By default, the HTTP metadata providers perform HTTP conditional GET
but they do not cache the response body, and moreover, the cached HTTP
headers do not survive a restart.
Yes, for the batch ones.  The dynamic HTTP one does not cache the conditional GET headers internally, it delegates both conditional GET and response body caching to the HttpClient caching layer, and for that it defaults to 'memory'.  As the docs say.

- To cache the full HTTP response (including the response body) set
the httpCaching attribute to either “file” or “memory”.

Yes.

- The full HTTP response will survive a restart if (and only if)
httpCaching=”file”.

No, 'file' doesn't survive restarts.  The point of that is disk-based caching to eliminate memory usage, not to be persistent across restarts.


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman



On 5/3/18 2:05 PM, Brent Putman wrote:


No, 'file' doesn't survive restarts.  The point of that is disk-based caching to eliminate memory usage, not to be persistent across restarts.

IIRC there's also a technical reason wrt HttpClient.  It unfortunately doesn't cache the response headers on disk, only the response body.  The response headers live only in memory. I guess their idea is to store the frequently-needed and low-footprint data in memory, and put the less-frequently-needed and large-footprint stuff on disk.

So at least on the version we're currently using it's not even possible to make the HttpClient cache persist in a meaningful way across restarts.  Maybe that has or will change in the newer or future versions, don't know.

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
In reply to this post by Brent Putman
On Thu, May 3, 2018 at 2:05 PM, Brent Putman <[hidden email]> wrote:

>
> On 5/3/18 1:46 PM, Tom Scavo wrote:
>
> - By default, the HTTP metadata providers perform HTTP conditional GET
> but they do not cache the response body, and moreover, the cached HTTP
> headers do not survive a restart.
>
> Yes, for the batch ones.  The dynamic HTTP one does not cache the
> conditional GET headers internally, it delegates both conditional GET and
> response body caching to the HttpClient caching layer, and for that it
> defaults to 'memory'.  As the docs say.

What happens if httpCaching is set to "none" on DynamicHTTPMetadataProvider?

> - The full HTTP response will survive a restart if (and only if)
> httpCaching=”file”.
>
> No, 'file' doesn't survive restarts.  The point of that is disk-based
> caching to eliminate memory usage, not to be persistent across restarts.

Hmm, okay, then the docs are wrong. I'll fix that eventually (unless
you beat me to it).

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Brent Putman



On 5/3/18 2:10 PM, Tom Scavo wrote:
On Thu, May 3, 2018 at 2:05 PM, Brent Putman [hidden email] wrote:

What happens if httpCaching is set to "none" on DynamicHTTPMetadataProvider?

There will be no HTTP caching, so when it doesn't have a non-expired EntityDescriptor in memory for an entityID, it will always issue an HTTP request.


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
Hmm, I thought I understood but maybe not. Please be patient with me
as I probe further. I really do want to know how this works.

On Thu, May 3, 2018 at 2:25 PM, Brent Putman <[hidden email]> wrote:

>
> On 5/3/18 2:10 PM, Tom Scavo wrote:
>
> On Thu, May 3, 2018 at 2:05 PM, Brent Putman <[hidden email]> wrote:
>
> What happens if httpCaching is set to "none" on DynamicHTTPMetadataProvider?
>
> There will be no HTTP caching, so when it doesn't have a non-expired
> EntityDescriptor in memory for an entityID, it will always issue an HTTP
> request.

And that request will be an HTTP conditional request, right? If the
response comes back 304, I assume it uses the EntityDescriptor in
memory. The downside is, when httpCaching="none", it always goes out
to the network.

OTOH, if httpCaching="memory", it tries to use the EntityDescriptor
cached in memory without issuing a request. (Same with
httpCaching="file", I suppose.) If the cached file becomes
cache-invalid, an HTTP conditional request is issued. Regardless of
the response (200 or 304), the cache is refreshed.

For FileBackedHTTPMetadataProvider, the default is httpCaching="none",
so again it always goes out to the network. If you configure
httpCaching="file", it goes to cache first, but since
FileBackedHTTPMetadataProvider has no cacheDuration settings, file
caching serves no purpose unless the metadata itself has a
cacheDuration XML attribute. In any case, make sure
httpMaxCacheEntrySize is large enough to accommodate the file (which
can be quite large).

For FileBackedHTTPMetadataProvider, I don't see a use for
httpCaching="memory", except perhaps for individual entity
descriptors. Which reminds me, is there a way to batch load a bunch of
individual entity descriptors? The use case is pre-loading of
high-value entities.

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Cantor, Scott E.
On 5/3/18, 4:33 PM, "Tom Scavo" <[hidden email]> wrote:

> And that request will be an HTTP conditional request, right?

No.

> The downside is, when httpCaching="none", it always goes out to the network.

No. There's *no* HTTP caching implemented by the dynamic code, it's left to the client bean. The batch providers have done a limited conditional GET form of caching for a while, independent of the client bean, they just don't physically cache response bodies in the HTTP sense.

The dynamic providers always decide whether to "try to get something new" and if they do, and the back-end is HTTP, then it just asks the client to issue a GET. What happens then is up to the client.

> For FileBackedHTTPMetadataProvider, I don't see a use for
> httpCaching="memory", except perhaps for individual entity
> descriptors. Which reminds me, is there a way to batch load a bunch of
> individual entity descriptors? The use case is pre-loading of
> high-value entities.

LocalDynamic can do that, effectively, if not explicitly.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Client Attributes

Tom Scavo
In reply to this post by Rod Widdowson
On Thu, May 3, 2018 at 11:11 AM, Rod Widdowson <[hidden email]> wrote:

>
> From the code:  The following attributes cause a warning to be emitted if present with a httpClientRef
>
>         requestTimeout
>         connectionTimeout
>         connectionRequestTimeout
>         socketTimeout
>         disregardSslCertificate
>         disregardTLSCertificate
>         proxyHost
>         proxyPort
>         proxyUser
>         proxyPassword

In addition, from what Brent has said, the following attributes are
also incompatible with httpClientRef:

- maxConnectionsTotal
- maxConnectionsPerRoute
- httpCaching
- httpCacheDirectory
- httpMaxCacheEntries
- httpMaxCacheEntrySize

I don't know if these should emit a warning as well but if you want me
to file an issue, just let me know.

I'm still not sure about the following attributes:

- basicAuthUser
- basicAuthPassword
- tlsTrustEngineRef
- httpClientSecurityParametersRef

Are these compatible with httpClientRef?

Assuming the answer is no in all cases, I summarized *all* of the HTTP
attributes in my personal space:
https://wiki.shibboleth.net/confluence/x/rQHKAg

Comments and edits are welcome.

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
12