I just saw the comment from Daniel Kulp on CXF-6475. Great find, thanks! I'll
comment further on the JIRA ticket.
On Thursday, June 25, 2015 5:41 PM, LBC <[email protected]> wrote:
I modified the code to reveal the URIs and updated CXF-6475 with a comment.
The built URIs from CXF and Jersey appear to be identical.
Unfortunately, I don't have the cycles w/ work to dig into it further than
that, but I'll Brian Risk from Quandl support (the WS provider) to comment on
what conditions would generate the 301 response.
On Thursday, June 25, 2015 2:10 PM, Sergey Beryozkin <[email protected]>
wrote:
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
>
>
>
>
>
>
