[Bug 57804] HTTPS doesn't reuse cache SSL context

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57804

Rainer Jung <ra...@kippdata.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |---
             Status|RESOLVED                    |REOPENED

--- Comment #3 from Rainer Jung <ra...@kippdata.de> ---
I just ran into the same problem and did a little analysis:

It happens with the HC4 sampler (don't know about the others) when used with
client certs. HC4 uses a pool that compares two things to find an adequate
connection: the HttpRoute (target host, proxies etc.) and a "state" Object.

If the state Object is null, then HC4 will only return a connection who's state
is also null. If it is not null, the state of the connection must have the same
state value. Now state is not something like closed or opened or so. Instead by
default if no state is present, HC4 determines a state at the end of the
request using a UserTokenHandler. The default UserTokenHandler will set the
state of a connection at the end of the request to the value of the client cert
used in the SSL session. But JMeter always requests a connection with null
state value, so a previously used connection will never match,

I don't have a fix ready, but since currently the requested state - null - and
the state a connection is set to after use - the client cert - never matches,
we either need to make sure, that we request a connection for the correct
state, or that the state of a connection is not set or set to a stete we use
when requesting the connection.

Example:

Set the state to something sensible before running the request: the state can
be injected using

localContext.setAttribute(ClientContext.USER_TOKEN, "dummy");

in JMeter HTTPHC4Impl between creating localContext and calling
executeRequest().
HC4 will then take the state from the context and not try to determine it using
the SSL Session. For the first request, a new connection has to be created and
when it is released is will be branded using the provided state. Next time we
need a connection, if we ask for the same state, we will get the same
connection back. So if we have a good concept of the correct state Object, we
could fix it that way.

So far for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.