Hi,

I have observed something similar in following case: both client and service 
use streaming, but client is not making any attempt to "read" the response 
object. The server is trying to stream the data back to the client and is 
waiting for the client to "read" some data so it can send more.
That works fine for small messages fit to buffer, but causes error for larger 
once.
Details in https://issues.apache.org/jira/browse/CXF-4480.

Not sure that it is related to your case.

Regards,
Andrei.

From: Laura Laurka [mailto:[email protected]]
Sent: Freitag, 11. Oktober 2013 00:32
To: [email protected]
Subject: ssl http POST request size limit issue

Hi,
with CXF 2.6 I am posting a SOAP messages to the https based web service using 
client side SSL certificates.

When the SOAP messages is 11 KB or less, I observed no problems and SSL 
communication(negotiation) + http request end successfully.
When my post is bigger than 16KBs server returns error 500. I have no such 
errors with HTTP POST (for requestes 16kb and bigger) when using different 
tools such as 'curl' or 'wget' so I assume there is no problem with the web 
service but rather with the way I use CXF.

I tried with JDK 6, and 7 from Oracle and IBM JDK and the issue was 
reproducible.

I used then tracing SSL mechanism from JDK.
http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDebug.html

Trace shows that SSL negotiation is successful and then following happens, 
first HTTP header, then POST request:
%% Cached client session: [Session-1, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
[read] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C DA 1B DE DA   3C B6 D0 78 03 B0 C6 B7  ........<..x....
Padded plaintext before ENCRYPTION:  len = 840
0000: 50 4F 53 54 20 2F 42 32   42 5F 4F 50 53 5F 31 37  POST /B2B_OPS_17

Content-type: text/xml
Content-Lengt: 16840

default-workqueue-2, WRITE: TLSv1 Application Data, length = 840
[Raw write]: length = 845

then I have binary information of the HTTP header

then

Padded plaintext before ENCRYPTION:  len = 16408

And SOAP body starts.
...
Before I see whole SOAP body in the ascii output at almost the end of the SOAP 
message (but not complete) I have:
default-workqueue-2, WRITE: TLSv1 Application Data, length = 16408
[Raw write]: length = 16413

then binary SOAP debug information follows.
and then
Padded plaintext before ENCRYPTION:  len = 480

and I see the rest of my SOAP request followed by:
default-workqueue-2, WRITE: TLSv1 Application Data, length = 480
[Raw write]: length = 485


Looks like if SOAP body is smaller (for example 11 kb) I do not observe such 
http body 'split' to two sections in the JVM debug output.

What could be the reason of such behavior?

I observed that if body is split in the JVM debug output then I get http 500 
error from my remote web service. If the SOAP message is complete in one 
section of the JVM debug then HTTP post is successful.

Cheers,




Reply via email to