You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Laura Laurka <la...@icloud.com> on 2013/10/11 00:32:01 UTC
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,
RE: ssl http POST request size limit issue
Posted by Andrei Shakirin <as...@talend.com>.
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:laurczak@icloud.com]
Sent: Freitag, 11. Oktober 2013 00:32
To: users@cxf.apache.org
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,