You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2008/07/11 19:12:29 UTC
Re: Can an HTTP server close the socket before its client has
finished receiving the message?
On Fri, 2008-07-11 at 12:43 +0200, Ortwin Glück wrote:
> Asanka,
>
> The exact timing of the remote side closing the connection shouldn't matter. If
> coded propertly, buffers are flushed before/on close. The TCP FIN sequence will
> be queued *after* all the data packets. So the data will remain within the TCP
> stack and is not lost, even if the client starts reading long after the
> connection has been closed. A packet dump (Wireshark) should give us more
> information here.
>
> Ortwin
>
Asankha,
The most plausible cause of this problem is a failure to flush the
output buffer on the server side. Given this is Weblogic, which is known
to be very stable, I admit this assumption does seem far fetched. So, I
would not rule out HttpCore SSL session behaving funny for some reason.
What version of Weblogic is it? Is it fully patched?
Please let me know if I can help you in any way.
Oleg
> Asankha C. Perera wrote:
> > Hi All
> >
> > When talking over SSL to a BEA WLI server, it responds with a
> > "Connection: close" header, and seems to close the socket, before Apache
> > Synapse (using HttpCore/NIO) could read the full message (~11K in size).
> > Its setting the 'Content-length' header, but when debugging the SSL
> > communication, we see that the full reply never reaches the client.
> >
> > 0580: 22 68 74 74 70 3A 2F 2F 77 77 77 2E 69 62 7A 2E "http://www.xxx.
> > 0590: 72 72 6E 2E 66 67 6F 76 2E 62 65 2F 58 53 44 2F xxx.xxxx.xx/XSD/
> > 05A0: 78 6D 32 35 2F 72 6E 32 D7 DF 5D F5 F3 3F F2 10 xm25/rn2..]..?..
> > 05B0: EB C2 AF F9 C4 F7 B4 49 .......I
> > 2008-07-10 23:49:01,959 [127.0.1.1-asankha] [I/O dispatcher 2] DEBUG
> > SSLIOSession I/O session sslclient-4 [interested ops: [r]; ready ops:
> > [r]][SSL handshake status: NOT_HANDSHAKING][1901][0][0][0]: 1448 bytes read
> > 2008-07-10 23:49:01,959 [127.0.1.1-asankha] [I/O dispatcher 2] DEBUG
> > SSLIOSession I/O session sslclient-4 [interested ops: [r]; ready ops:
> > [r]][SSL handshake status: NOT_HANDSHAKING][1901][0][0][0]: -1 bytes read
> > 2008-07-10 23:49:01,977 [127.0.1.1-asankha] [HttpClientWorker-2] ERROR
> > AxisEngine Error in extracting message properties
> > org.apache.axis2.AxisFault: Error in extracting message properties
> >
> > Is this something possible when using "Connection: close" ? and if so,
> > what can a client do to prevent loosing the reply
> >
> > thanks
> > asankha
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Can an HTTP server close the socket before its client has finished receiving the message?
Posted by Mike Dillon <mi...@embody.org>.
begin Oleg Kalnichevski quotation:
> On Fri, 2008-07-11 at 19:19 +0200, Ortwin Glück wrote:
> >
> > Oleg Kalnichevski wrote:
> > > The most plausible cause of this problem is a failure to flush the
> > > output buffer on the server side. Given this is Weblogic, which is known
> > > to be very stable, I admit this assumption does seem far fetched. So, I
> > > would not rule out HttpCore SSL session behaving funny for some reason.
> >
> > A packet dump would reveal who's to blame.
> >
>
> I am not sure it is that easy for SSL encrypted traffic. Can Wireshark
> decrypt SSL packets? We only know the expected length of unencrypted
> content.
Yes, Wireshark can decrypt SSL traffic if it has the server's key:
http://wiki.wireshark.org/SSL#head-37089fe34751c3129d84971ec4d83ad0322d35e1
It looks like it needs compiled with Gnu-TLS for this to work.
-md
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Can an HTTP server close the socket before its client has finished
receiving the message?
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> On Fri, 2008-07-11 at 19:19 +0200, Ortwin Glück wrote:
>> Oleg Kalnichevski wrote:
>>> The most plausible cause of this problem is a failure to flush the
>>> output buffer on the server side. Given this is Weblogic, which is known
>>> to be very stable, I admit this assumption does seem far fetched. So, I
>>> would not rule out HttpCore SSL session behaving funny for some reason.
>> A packet dump would reveal who's to blame.
>>
>
> I am not sure it is that easy for SSL encrypted traffic. Can Wireshark
> decrypt SSL packets? We only know the expected length of unencrypted
> content.
>
> Oleg
Right, that could be a problem :-) Does this only happen over SSL?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Can an HTTP server close the socket before its client
has finished receiving the message?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2008-07-11 at 19:19 +0200, Ortwin Glück wrote:
>
> Oleg Kalnichevski wrote:
> > The most plausible cause of this problem is a failure to flush the
> > output buffer on the server side. Given this is Weblogic, which is known
> > to be very stable, I admit this assumption does seem far fetched. So, I
> > would not rule out HttpCore SSL session behaving funny for some reason.
>
> A packet dump would reveal who's to blame.
>
I am not sure it is that easy for SSL encrypted traffic. Can Wireshark
decrypt SSL packets? We only know the expected length of unencrypted
content.
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Can an HTTP server close the socket before its client has finished
receiving the message?
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> The most plausible cause of this problem is a failure to flush the
> output buffer on the server side. Given this is Weblogic, which is known
> to be very stable, I admit this assumption does seem far fetched. So, I
> would not rule out HttpCore SSL session behaving funny for some reason.
A packet dump would reveal who's to blame.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Can an HTTP server close the socket before its client has finished
receiving the message?
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Oleg, Ortwin and Mike
Sorry for my delay in responding,.. I am unable to find out the version
of Weblogic, but will try to find that out. I will also try to get a
tcpdump or a wireshark dump to investigate this further and share that
with you. I am accessing this service histed in Europe, over a VPN from
Sri Lanka, but I guess that will [hopefully] not spoil a tcpdump or
wireshark dump.. Also this service is available only over https, so I am
unable to say of this is specific to https, but will try to find more
details and update you
many thanks
asankha
>> The exact timing of the remote side closing the connection shouldn't matter. If
>> coded propertly, buffers are flushed before/on close. The TCP FIN sequence will
>> be queued *after* all the data packets. So the data will remain within the TCP
>> stack and is not lost, even if the client starts reading long after the
>> connection has been closed. A packet dump (Wireshark) should give us more
>> information here.
>>
>> Ortwin
>>
>>
>
> Asankha,
>
> The most plausible cause of this problem is a failure to flush the
> output buffer on the server side. Given this is Weblogic, which is known
> to be very stable, I admit this assumption does seem far fetched. So, I
> would not rule out HttpCore SSL session behaving funny for some reason.
>
> What version of Weblogic is it? Is it fully patched?
>
> Please let me know if I can help you in any way.
>
> Oleg