> From: dthomp...@prinpay.com
> To: openssl-users@openssl.org
> Subject: RE: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL
> using axis2c
> Date: Mon, 6 Feb 2012 20:43:28 -0500
>
> > From: owner-openssl-us...@openssl.org On Behalf Of manoj dhyani
> > Sent: Saturday, 04 February, 2012 23:59
>
> > both soapUI and client application built using axis 2c are running
> > on the same machine, I have axis2java based client running on the
> > same machine and works fine
>
> > the request is hot very big, the webserver requires WS-Security
> > username and password, but if you don't pass that it returns a soap fault
> > in case of SopUI and axis2java but fails with the same error for axis2c
>
> > the buffer in axis2c is null, I do see encrypted alter and connection
> reset
> > after FIN
> > I am attaching the wireashark capture both when the call is done
> from
> > SoapUI and Axis2c client
>
> Okay, in the good case (SoapUI) after handshake
> (resulting in TLS1.0 RSA-RC4-128-SHA) we have:
> #17 send enc-data 559-20=539
> #18,19 recv enc-data 1471-20=1451
> #21 recv enc-data 69-20=49
> #22 send enc-data 762-20=742
> about .4sec delay to #23 ACK and another .4sec to
> #24,25,27,28,30,31,33,34,36 recv enc-data 12218-20=12198
>
> 539 is about right to be HTTPhdr plus a smallish request;
> 1451 + 49 could be a segmented response (but see next)
> or a response with some HTTP control like chunked encoding.
> 742 could be a slightly larger request and 12198 a big response
> (not segmented, but maybe from a different part of server).
>
> In the bad case (app+axis2) there's 4.5sec delay starting handshake
> which I'll hope was just debugging, then after handshake we have:
> #15 send enc-data 204-20=184
> #16 send enc-data 22-20=2
> #17 send enc-data 944-20=924
> about .2sec delay maybe Nagle then recv ACK(#16) and ACK(#17) then
> #20 recv enc-alert with piggyback FIN (with PSH ACK)
> #21 send ACK(#20+FIN) not FIN (probably in stack)
> #22 recv RST (with ACK and good ack/seq)
>
> The server apparently dislikes your request and closes
> aggressively: it RSTs to your machine's ACK(FIN) even
> though it may still have seqctrs and (thus) endpoint block,
> and even though you haven't begun to FIN. This is not ideal
> TCP behavior, though it can be acceptable in an error case.
>
> It looks very odd that your request is sent as 184,2,924.
> 184 is enough for HTTPhdr but little or no request data.
> 2 is a very odd size to do in the middle. Total 1110 is
> noticeably more than 539 for first request in good case.
>
> Since you can debug, I would look at the calls to SSL_write,
> and verify that when concatenated they form a valid request
> (HTTPhdr then SOAP request body), and try to look at the calling
> (axis2c) code to see why it's sending in pieces like this.
> Though in itself legal that behavior is somewhat unusual, and
> might be triggering a server limitation the other case doesn't.
>
> Hope this helps.
Thanks ! yes, this helped
the 2 bytes that you see in bad case is CRLF (carriage return and line feed),
axis2c is sending this after sending the HTTP Header and before sending the
Soap Request, but this is not causing any issue
after debugging found that there is a difference in the way axis2c is sending
the HOST parameter in the HTTP Header
in case of axis2c it's adding the post number to the hostname
Host: nestlepreview.i-nexus.com:443
where as in case of SoapUI only hostname is sent
Host: nestlepreview.i-nexus.com
if I change the Axis2c code to not suffix port it works fine, not sure if this
is Axis2c bug or server side issue,
I don't see any issue with other HTTPS webservices using default port when
invoked using Axis2c client app
let me post this in Axis2c forum and see if there is any way to control this
parameter, looking at the code I didn't see any thing
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
