Issue with Nokia HttpConnection.flush()

Ricardo Scholz <[email protected]> Mon, 22 Jun 2009 17:25:46 -0300
Newsgroups gmane.comp.java.sun.kvm
Message-ID <[email protected]>
--00151751138ee26a15046cf5ad5b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello everybody,

I've been trying to implement a client-server application that exchanges
byte arrays through a HTTP connection. My client-server application works
fine with a Motorola V3, but when I try to connect from a Nokia 5310
XpressMusic, the input stream in the server cannot be read (it comes empty)=
.
I used a software that receives the connection and forwards the request to
the server, to see some information about what was being sent by the
clients, so I got the information below:

In the successful Motorola version, the header parameters are:

content-length: -1 (although I explicitly set it to the byte array length)
connection: close (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
transfer-encoding: chunked (implicitly set)

and the actual data sent has the chunked formatting (the chunk size
prepended and a zeroed chunk size to inform the end of the chunks sequence)=
,
as below:

29
3333223=1Dcdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96<=93=94=95=96=97=98r=99=
=9A=9B
0

In the other hand, the unsuccessful Nokia version has the following header
parameters:

content-length: <the actual data length> (explicitly set)
connection: keep alive (implicitly set)
content-type: application/x-www-form-urlencoded (explicitly set)
<no transfer-encoding parameter set>

and the actual data sent does not have the chunked formating, as below:

3333223=1Dcdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96<=93=94=95=96=97=98r=99=
=9A=9B

I used pretty much the networking implementation as defined in the API. In
addition, as far as I could understand, the call to HttpConnection.flush()
sets the transfer-encoding header parameter to chunked, but it only works
for the Motorola version. Without it, none of the two versions works fine,
as it seems that the server can only deal with chunked data.

I've tried to find something in the Forum Nokia, KVM-Interests archives and
Google, but without actual success.

If you guys have any idea on how to work this around, either in the client
application or in the server application, I'd appreciate.

Many thanks.

Best regards,

Ricardo Scholz.

--=20
ricardo]scholz
meantime]mobile.creations
+55[81]8664.8665

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

--00151751138ee26a15046cf5ad5b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello everybody,<br><br>I&#39;ve been trying to implement a client-server a=
pplication that exchanges byte arrays through a HTTP connection. My client-=
server application works fine with a Motorola V3, but when I try to connect=
 from a Nokia 5310 XpressMusic, the input stream in the server cannot be re=
ad (it comes empty). I used a software that receives the connection and for=
wards the request to the server, to see some information about what was bei=
ng sent by the clients, so I got the information below:<br>
<br>In the successful Motorola version, the header parameters are:<br><br>c=
ontent-length: -1 (although I explicitly set it to the byte array length)<b=
r>connection: close (implicitly set)<br>content-type: application/x-www-for=
m-urlencoded (explicitly set)<br>
transfer-encoding: chunked (implicitly set)<br><br>and the actual data sent=
 has the chunked formatting (the chunk size prepended and a zeroed chunk si=
ze to inform the end of the chunks sequence), as below:<br><br>29<br>333322=
3=1Dcdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96&lt;=93=94=95=96=97=98r=99=9A=
=9B<br>
0<br><br>In the other hand, the unsuccessful Nokia version has the followin=
g header parameters:<br><br>content-length: &lt;the actual data length&gt; =
(explicitly set)<br>connection: keep alive (implicitly set)<br>content-type=
: application/x-www-form-urlencoded (explicitly set)<br>
&lt;no transfer-encoding parameter set&gt;<br><br>and the actual data sent =
does not have the chunked formating, as below:<br><br>3333223=1Dcdefghijkb=
=96=9F5=A9=A6=9C=936=93=94=95=96&lt;=93=94=95=96=97=98r=99=9A=9B<br><br>I u=
sed pretty much the networking implementation as defined in the API. In add=
ition, as far as I could understand, the call to HttpConnection.flush() set=
s the transfer-encoding header parameter to chunked, but it only works for =
the Motorola version. Without it, none of the two versions works fine, as i=
t seems that the server can only deal with chunked data.<br>
<br>I&#39;ve tried to find something in the Forum Nokia, KVM-Interests arch=
ives and Google, but without actual success.<br><br>If you guys have any id=
ea on how to work this around, either in the client application or in the s=
erver application, I&#39;d appreciate.<br>
<br>Many thanks.<br><br>Best regards,<br><br>Ricardo Scholz.<br><br>-- <br>=
ricardo]scholz<br>meantime]mobile.creations<br>+55[81]8664.8665<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

--00151751138ee26a15046cf5ad5b--