OK, just because it is very frustrating to see post with unsolved problems,
I managed to solve mine, and wanted to let you know.
Actually, after a disconnection, the socket was closed by my server
application. When the network was back, my Android app send a request to the
server that was not we
I changed my code, and replaced
org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory() by
android.net.SSLCertificateSocketFactory.getDefault(TIMEOUT).
It's working perfect for emulator and devices in version 2.2 (API Level 8),
but it doesn't work for version 2.1-update1... It still seem to
Thanx Kostya for you suggestion. I will try to have a look at this session
caching : I think the issue could come from this.
I'm not using HTTP : I use socket. But I was using apache because it
simplifies a bit the code for certificate validation.
@IndicatorVeritatis : the read method on a socke
For a blocking stream, -1 is closed.
The issue with SSL sockets in HTTP code failing in some way or other comes
up on this list every once in a while.
Think I remember a suggestion to disable SSL session cacheing (negotiated
SSL sessions are cached and reused, if the code sees the same pair of
en
I think you may be jumping the gun by assuming that read() returning
-1 means the stream is invalid: what it REALLY means is only that the
end of the stream has been reached, there are no more bytes to read:
it does not explain WHY there are no more to read. How can you exclude
the possibility that
5 matches
Mail list logo
