03-15-2013 04:48 AM
I am currently testing whether gzips works, as I'm planning to use gzip compression on the server. The app has been running fine on all devices and connection types, but as soon as I use gzip compression on the server, I get the following error:
vice.api.io.ConnectionClosedException: Not connected)
The exception is thrown when I am trying to open the connection (where connectString is the URL along with the transport selectors, e.g. ;deviceside=true):
connection = (HttpConnection)Connector.open(connectString, Connector.READ_WRITE, true)
In my HTTP Headers, the Accept-Encoding header also contains gzip.
Any idea what could cause this issue?
03-15-2013 11:04 AM - edited 03-15-2013 11:04 AM
Can you be more specific as to at what point the exception is being thrown? Is it when you connect or when you are reading the response? Are you using GZipInputStream?
03-15-2013 11:14 AM
Can you confirm that you are in fact using an "https://...." URL?
I am surprised by this statement:
"In my HTTP Headers, the Accept-Encoding header also contains gzip."
You normally don't set the headers until you have got a connecion. How do you set this before you do the open?
Is this failure on device or on the Simualtor? Specific OS's involved?
Can I ask that you replace the "catch (Excpetion ..)" with a "catch (Throwable t", and then print the stack trace (t.printStackTrace()) - it woud be interesting to see what processing throws this exception.
My experience with gzip compression is that it works well. but I have never used it with a secure connection.
03-18-2013 01:27 AM
Thanks for your quick reply.
Yes, I can confirm that I am using an "https://" URL.
Sorry, my statement on the header wasn't very clear. What I meant was that prior to this issue, the requests that arrived the server from the devices and simulator contained the Accept-Encoding header with gzip among its values. I haven't explicitly set the header in my code and if I had to, it would of course be after the connection.
As I haven't had access to any test devices durin the past few days, I have only tested on the simulator (OS 6.0, OS 7.0, different devices), whereby the issue always occurred.
I am already catching the exception as Throwable, but so far only checked the message, which was always null. I'll print the stack trace and let you know about the result.
03-18-2013 05:38 AM
Here is the stack trace of the exception being thrown:
TLSIOException No detail message net_rim_os-2(4C48E1DA) ClientProtocol <private> 0x11D0 net_rim_os-2(4C48E1DA) ClientProtocol ensureOpen 0xE9F net_rim_os-2(4C48E1DA) ClientProtocol <init> 0x1DA3 net_rim_os-2(4C48E1DA) Protocol <private> 0x7667 net_rim_os-2(4C48E1DA) Protocol openConnection 0x753B net_rim_os-3(4C48E1DA) Protocol openPrim 0x6BB4 net_rim_os-3(4C48E1DA) Protocol openPrim 0x6BFF net_rim_cldc-24(4C48DD41) RIMConnector <private> 0x8348 net_rim_cldc-24(4C48DD41) RIMConnector open 0x7EB5 net_rim_cldc-2(4C48DD41) Connector open 0x810
And here is a screenshot of the stack trace as shown by the debugger:
03-18-2013 06:08 AM
I don't think I can help much here as I have no experience of this However I am not convinced that GZIP has anything to do with this.
If you are creating the http connection yourself, then unless you actually set the header, I can't see that the header will be set to accept GZIP. If you don't set it and the request turns up on the server with this header, then I suggest the gateway you are using is putting it in. Try the request over WiFi. This is a gateway issue.
I think the same regarding the connection problem. As far as I know, the initial communication over an https connection establishment is just to get the appropriate credentials for a Secure Socket connection. If you look at the log you will see this activity, as the device and server negotiate. This is just to establish the socket over which you will send the HTTP request (and it is the HTTP request that contains the headers). At this point, neither end knows if they are going to use gzip.
In summary I suspect gzip is red herring, I think you should be looking at other causes of this issue. Specifically I would start looking at the connection methods that I am trying and the gateways involved in achieving this. Normally WiFi is a safe bet as there are no carrier gateways involved normally.
03-18-2013 09:12 AM
Makes sense ... I think I'll have a closer look on the HTTPS connection used and if this could cause the problem.
However, I really appreciate your help so far. Thank you!