Thanks for the analysis so far. It does not really bring us any closer
to finding where the problem is.
Try the following:
1. Compare URIs created by CXF and Jersey. There has to be some
difference, possibly a subtle one somewhere.
2. Check if CXF sends multiple requests - may be the target service
challenges the client or auto redirects.
3. Find out from the provider under what conditions 301 is returned and
if necessary ask them to provide with some more details.
4. Rewrite the code a bit and try CXF WebClient and initialize it with
LoggingFeature (a note to myself - add a JAX-RS Feature wrapper around
CXF Feature)
The client code is very straightforward and I do not see the reason it
would not work. Please keep investigating
Cheers, Sergey
On 25/06/15 21:08, LBC wrote:
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
