I've attached the tcpdump files to the ticket:
https://issues.apache.org/jira/browse/CXF-6475
BTW, I don't have access to the server side as I'm the WS consumer. I do have
a support agreement with the WS provider though so if necessary I can possibly
request logs from them. However, it would seem this issue has more to do w/
CXF.
On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin
<[email protected]> wrote:
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
