Re: Issue with Nokia HttpConnection.flush()

Roger <[email protected]> Tue, 23 Jun 2009 10:14:16 +0200
Newsgroups gmane.comp.java.sun.kvm
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------050502020506070000050001
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by brmea-mail-4.sun.com id n5N8ESFU026844

Hi Ricardo,

no, You can't take influence on the transfer-encoding. Motorola uses=20
chunked, Nokia doesn't. So it's an absolute must to write the=20
content-length to the header for Nokia phones.

But why on earth do you set the content-type? In my opinion you should=20
leave it out unless you really encode you data properly before streaming =
it.

flush() doesn't influence the transfer-encoding at all. It simply=20
empties the internal buffer. Besides flush ist called automatically,=20
when closing a connection.

Do you close the connection? If the header says "connection:=20
keep-alive", you have to do so. Otherwise the server ist waiting for=20
content until tomorrrow.

Best,

Roger



Ricardo Scholz schrieb:
> Hi All,
>
> There's a mistake in the first message, when I said=20
> HttpConnection.flush() I meant OutputStream.flush().
>
> Hi Chris,
>
> Thanx for your reply. Yes, you're right. Setting the content-length=20
> makes no sense if the chunked protocol prepends each chunk length at=20
> the beginning of the chunks. The Motorola version content-length is=20
> overwritten to -1, and works fine.
>
> My question is: why the Nokia version does not overwrite the=20
> content-length property to -1 when I call OutputStream.flush() [what=20
> seems to be the method that makes transfer-encoding be changed to=20
> chunked in the Motorola version]? Also, this method does not make the=20
> transfer-encoding be changed to chunked, nor actually includes the=20
> prepended chunks length in the message body [it seems to infuence both=20
> in the Motorola version].
>
> I can't underestand how to get control of 'chunking' turnning on/off.=20
> (I don't even know whether it is possible or not).
>
> I'll try without setting the content-length (as setting it is useless=20
> and makes no sense anyway ;)
>
> Best regards,
>
> Ricardo.
>
> On Mon, Jun 22, 2009 at 11:21 PM, Chris B <[email protected]=20
> <mailto:[email protected]>> wrote:
>
>     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)
>     =20
>     =20
>     you cant have a chunked with a content length! it's one or the othe=
r.
>     =20
>
>         ----- Original Message -----
>         *From:* Ricardo Scholz <mailto:[email protected]>
>         *To:* [email protected]
>         <mailto:[email protected]>
>         *Sent:* Monday, June 22, 2009 9:25 PM
>         *Subject:* Issue with Nokia HttpConnection.flush()
>
>         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 cdefghijkb=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 cdefghijkb=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]
>         <mailto:[email protected]> and include in the body of the
>         message "signoff KVM-INTEREST". For general help, send email
>         to [email protected] <mailto:[email protected]> and
>         include in the body of the message "help".=20
>
>     =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]
>     <mailto:[email protected]> and include in the body of the
>     message "signoff KVM-INTEREST". For general help, send email to
>     [email protected] <mailto:[email protected]> and include
>     in the body of the message "help".=20
>
>
>
>
> --=20
> ricardo]scholz
> +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=20
> To unsubscribe, send email to [email protected] and include in the=20
> body of the message "signoff KVM-INTEREST". For general help, send=20
> email to [email protected] and include in the body of the message=20
> "help".=20

--=20
/**************************
* Roger F. H=F6sl
* ...
**************************/


=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 bo=
dy
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

--------------050502020506070000050001
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by brmea-mail-4.sun.com id n5N8ESFU026844

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html;charset=3Dwindows-1252"
 http-equiv=3D"Content-Type">
  <title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000066">
<font size=3D"-1"><font face=3D"Verdana">Hi Ricardo,<br>
<br>
no, You can't take influence on the transfer-encoding. Motorola uses
chunked, Nokia doesn't. So it's an absolute must to write the
content-length to the header for Nokia phones. <br>
<br>
</font></font><font size=3D"-1"><font face=3D"Verdana">But why on earth d=
o
you set the content-type? In my opinion you should leave it out unless
you really encode you data properly before streaming it.</font></font><br=
>
<font size=3D"-1"><font face=3D"Verdana"><br>
flush() doesn't influence the transfer-encoding at all. It simply
empties the internal buffer. Besides flush ist called automatically,
when closing a connection.<br>
<br>
Do you close the connection? If the header says "connection:
keep-alive", you have to do so. Otherwise the server ist waiting for
content until tomorrrow.<br>
<br>
Best,<br>
<br>
Roger<br>
<br>
<br>
</font></font><br>
Ricardo Scholz schrieb:
<blockquote
 cite=3D"mid:[email protected]"
 type=3D"cite">Hi All,<br>
  <br>
There's a mistake in the first message, when I said
HttpConnection.flush() I meant OutputStream.flush().<br>
  <br>
Hi Chris,<br>
  <br>
Thanx for your reply. Yes, you're right. Setting the content-length
makes no sense if the chunked protocol prepends each chunk length at
the beginning of the chunks. The Motorola version content-length is
overwritten to -1, and works fine. <br>
  <br>
My question is: why the Nokia version does not overwrite the
content-length property to -1 when I call OutputStream.flush() [what
seems to be the method that makes transfer-encoding be changed to
chunked in the Motorola version]? Also, this method does not make the
transfer-encoding be changed to chunked, nor actually includes the
prepended chunks length in the message body [it seems to infuence both
in the Motorola version].<br>
  <br>
I can't underestand how to get control of 'chunking' turnning on/off.
(I don't even know whether it is possible or not).<br>
  <br>
I'll try without setting the content-length (as setting it is useless
and makes no sense anyway ;)<br>
  <br>
Best regards,<br>
  <br>
Ricardo.<br>
  <br>
  <div class=3D"gmail_quote">On Mon, Jun 22, 2009 at 11:21 PM, Chris B <s=
pan
 dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
 href=3D"mailto:[email protected]">[email protected]</a>&gt;</spa=
n>
wrote:<br>
  <blockquote class=3D"gmail_quote"
 style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;">
    <div bgcolor=3D"#ffffff">
    <div class=3D"im">
    <div>content-length: -1 (although I explicitly set it to the byte
array length)<br>
connection: close (implicitly set)<br>
content-type: application/x-www-form-urlencoded (explicitly set)<br>
transfer-encoding: chunked (implicitly set)</div>
    <div>=A0</div>
    <div>=A0</div>
    </div>
    <div><font face=3D"Arial" size=3D"2">you cant have a chunked with a
content length! it's one or the other.</font></div>
    <div>=A0</div>
    <blockquote
 style=3D"border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; paddin=
g-left: 5px; margin-left: 5px; margin-right: 0px;">
      <div>
      <div class=3D"h5">
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-size-adjus=
t: none; font-stretch: normal;">-----
Original Message ----- </div>
      <div
 style=3D"background: rgb(228, 228, 228) none repeat scroll 0%; -moz-back=
ground-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-bac=
kground-inline-policy: -moz-initial; font-family: arial; font-style: norm=
al; font-variant: normal; font-weight: normal; font-size: 10pt; line-heig=
ht: normal; font-size-adjust: none; font-stretch: normal;"><b>From:</b>
      <a moz-do-not-send=3D"true" title=3D"[email protected]"
 href=3D"mailto:[email protected]" target=3D"_blank">Ricardo Scholz=
</a>
      </div>
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-size-adjus=
t: none; font-stretch: normal;"><b>To:</b>
      <a moz-do-not-send=3D"true" title=3D"[email protected]"
 href=3D"mailto:[email protected]" target=3D"_blank">KVM-INTEREST=
@JAVA.SUN.COM</a>
      </div>
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-size-adjus=
t: none; font-stretch: normal;"><b>Sent:</b>
Monday, June 22, 2009 9:25 PM</div>
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-size-adjus=
t: none; font-stretch: normal;"><b>Subject:</b>
Issue with Nokia HttpConnection.flush()</div>
      <div><br>
      </div>
Hello everybody,<br>
      <br>
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:<br>
      <br>
In the successful Motorola version, the header parameters are:<br>
      <br>
content-length: -1 (although I explicitly set it to the byte array
length)<br>
connection: close (implicitly set)<br>
content-type: application/x-www-form-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 size to inform the end of the chunks
sequence), as below:<br>
      <br>
29<br>
3333223 cdefghijkb=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 following
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:<b=
r>
      <br>
3333223 cdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96&lt;=93=94=95=96=97=98r=
=99=9A=9B<br>
      <br>
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.<br>
      <br>
I've tried to find something in the Forum Nokia, KVM-Interests archives
and Google, but without actual success.<br>
      <br>
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.<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>
      </div>
      </div>
=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 <a moz-do-not-send=3D"true"
 href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
n.com</a>
and include in the body of the message "signoff KVM-INTEREST". For
general help, send email to <a moz-do-not-send=3D"true"
 href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
n.com</a>
and include in the body of the message "help". </blockquote>
    </div>
=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 <a moz-do-not-send=3D"true"
 href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
n.com</a>
and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
    <a moz-do-not-send=3D"true" href=3D"mailto:[email protected]"
 target=3D"_blank">[email protected]</a> and include in the body of
the message "help".
  </blockquote>
  </div>
  <br>
  <br clear=3D"all">
  <br>
-- <br>
ricardo]scholz<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 <a class=3D"moz-txt-link-abbreviated" href=3D=
"mailto:[email protected]">[email protected]</a> and include in t=
he
body
of the message "signoff KVM-INTEREST". For general help, send email to
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]=
m">[email protected]</a> and include in the body of the message "help=
".
</blockquote>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
/**************************
* Roger F. H=F6sl
* ...
**************************/</pre>
</body>
</html>
=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 bo=
dy
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

--------------050502020506070000050001--