Hi
You could've just posted a link to CXF-6475 to make it easier to read
this message.
I do not see where the issue is. HttpConduit logging is a bit confusing
indeed because there's a number of attempts to set TLS client parameters
but it does not mean that HTTPS is not used.
Can you trace the content of the request in a plain tcp trace utility ?
I'd say that no.
301 vs 200 does not mean it is not HTTPS.
The clue should be on the server side. Why 301, perhaps CXF produces a
slightly different URI compared to Jersey ? Does the server depend on
the order of the query parameters ?
Please investigate and let me know
Sergey
On 25/06/15 11:11, LBC wrote:
hi,
I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully
it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with
the associated Maven dependency, and the log output demonstrating the problem. Even
though I'm specifying a "https" URL, it seems CXF is making the request via
HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51).
I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same
test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
thanks,--Lawrence
