Re: Issue with Nokia HttpConnection.flush()
Ricardo Scholz <[email protected]> Tue, 23 Jun 2009 11:49:47 -0300
| Newsgroups | gmane.comp.java.sun.kvm |
|---|---|
| Message-ID | <[email protected]> |
--001517573d7823eb15046d051a56 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, it worked. Thank you all guys for your quick replies and attention. Roger, thanx for the information. It worked for both versions (Motorola and Nokia) by leaving the "content-type" out, seting the "content-length" properly and setting the "connection" property to "close". Just for the records, in case someone else has a similar problem: 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-len= gth > to the header for Nokia phones. > So, as far as I could understand, it's up to the kvm implementation (for instance, manufacturers) to define the transfer-encoding when implementing the HttpConnection. I have no control over it. > But why on earth do you set the content-type? In my opinion you should > leave it out unless you really encode you data properly before streaming = it. > I don't know why I set the content-type. During debug phase I've tried several approaches, and at some point, someone suggested me to set it to "application/x-www-urlencoded". > flush() doesn't influence the transfer-encoding at all. It simply empties > the internal buffer. Besides flush ist called automatically, when closing= a > connection. > Yes, that's what I read from the docs. But when I took away the 'flush()' call in the Motorola version, the packages started being transfered in a non-chunked way. Maybe I had changed something else at the same time that I'm missing now, and then I misinterpreted the results. > 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. > Now I set the "connection" parameter to close, and I close the OutputStream before calling HttpConnection.getResponseCode(). Thanx again. Best regards, Ricardo. > > > Ricardo Scholz schrieb: > > Hi All, > > There's a mistake in the first message, when I said HttpConnection.flush(= ) > I meant OutputStream.flush(). > > Hi Chris, > > 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 beginn= ing > of the chunks. The Motorola version content-length is overwritten to -1, = and > works fine. > > My question is: why the Nokia version does not overwrite the content-leng= th > property to -1 when I call OutputStream.flush() [what seems to be the met= hod > that makes transfer-encoding be changed to chunked in the Motorola versio= n]? > Also, this method does not make the transfer-encoding be changed to chunk= ed, > nor actually includes the prepended chunks length in the message body [it > seems to infuence both in the Motorola version]. > > I can't underestand how to get control of 'chunking' turnning on/off. (I > don't even know whether it is possible or not). > > I'll try without setting the content-length (as setting it is useless and > makes no sense anyway ;) > > Best regards, > > Ricardo. > > On Mon, Jun 22, 2009 at 11:21 PM, Chris B <[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) >> >> >> you cant have a chunked with a content length! it's one or the other. >> >> >> ----- Original Message ----- >> *From:* Ricardo Scholz <[email protected]> >> *To:* [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 work= s >> 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 emp= ty). >> 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 lengt= h) >> 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 sequen= ce), >> 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 head= er >> 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 work= s >> for the Motorola version. Without it, none of the two versions works fin= e, >> 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 clie= nt >> application or in the server application, I'd appreciate. >> >> Many thanks. >> >> Best regards, >> >> Ricardo Scholz. >> >> -- >> 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". >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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". > > > > > -- > 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 > 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". > > > -- > /************************** > * 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 > body of the message "signoff KVM-INTEREST". For general help, send email = to > [email protected] and include in the body of the message "help". > --=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 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". --001517573d7823eb15046d051a56 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, it worked. Thank you all guys for your quick replies and attention.= <br><br>Roger, thanx for the information. It worked for both versions (Moto= rola and Nokia) by leaving the "content-type" out, seting the &qu= ot;content-length" properly and setting the "connection" pro= perty to "close".<br> <br>Just for the records, in case=20 someone else has a similar problem:<br><br><div class=3D"gmail_quote"><bloc= kquote 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"#fffff= f" text=3D"#000066"> <font size=3D"-1"><font face=3D"Verdana"> 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. </font></font></div></blockq= uote><div><br>So, as far as I could understand, it's up to the kvm impl= ementation (for instance, manufacturers) to define the transfer-encoding when implemen= ting the HttpConnection. I have no control over it.<br>=A0</div><blockquote clas= s=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margi= n: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor=3D"#ffffff" text=3D"= #000066"> <font size=3D"-1"><font face=3D"Verdana"> </font></font><font size=3D"-1"><font face=3D"Verdana">But why on earth do 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></div= ></blockquote><div><br>I don't know why I set the content-type. During = debug phase I've tried several approaches, and at some point, someone s= uggested me to set it to "application/x-www-urlencoded".<br> =A0</div><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 bgc= olor=3D"#ffffff" text=3D"#000066"> <font size=3D"-1"><font face=3D"Verdana">flush() doesn't influence the = transfer-encoding at all. It simply empties the internal buffer. Besides flush ist called automatically, when closing a connection.</font></font></div></blockquote><div><br>Yes, th= at's what I read from the docs. But when I took away the 'flush()&#= 39; call in the Motorola version, the packages started being transfered in = a non-chunked way. Maybe I had changed something else at the same time that= I'm missing now, and then I misinterpreted the results.<br> =A0</div><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 bgc= olor=3D"#ffffff" text=3D"#000066"><font size=3D"-1"><font face=3D"Verdana"> 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> </font></font></div></blockquote><div><br>Now I set the "connection&qu= ot; parameter to close, and I close the OutputStream before calling HttpCon= nection.getResponseCode(). <font size=3D"-1"><font face=3D"Verdana"></font>= </font><br> =A0<br>Thanx again.<br><br>Best regards,<br><br>Ricardo.<br><br><br></div><= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor=3D"#f= fffff" text=3D"#000066"> <font size=3D"-1"><font face=3D"Verdana"><br> <br> </font></font><br> Ricardo Scholz schrieb: <div><div></div><div class=3D"h5"><blockquote 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 o= n/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 <spa= n dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>></span> 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> <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 size=3D"2" face=3D"Arial">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; padding-left: 5px; margin-left: 5px; margin-right: 0px;"> <div> <div> <div style=3D"font-family: arial; font-style: normal; font-variant: n= ormal; font-weight: normal; font-size: 10pt; line-height: normal; font-size= -adjust: none; font-stretch: normal;">----- Original Message ----- </div> <div style=3D"background: rgb(228, 228, 228) none repeat scroll 0% 50= %; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial= ; -moz-background-inline-policy: -moz-initial; font-family: arial; font-sty= le: normal; font-variant: normal; font-weight: normal; font-size: 10pt; lin= e-height: normal; font-size-adjust: none; font-stretch: normal;"> <b>From:</b> <a title=3D"[email protected]" href=3D"mailto:ricardoscholz@GMA= IL.COM" target=3D"_blank">Ricardo Scholz</a> </div> <div style=3D"font-family: arial; font-style: normal; font-variant: n= ormal; font-weight: normal; font-size: 10pt; line-height: normal; font-size= -adjust: none; font-stretch: normal;"><b>To:</b> <a title=3D"[email protected]" href=3D"mailto:KVM-INTEREST@JA= VA.SUN.COM" target=3D"_blank">[email protected]</a> </div> <div style=3D"font-family: arial; font-style: normal; font-variant: n= ormal; font-weight: normal; font-size: 10pt; line-height: normal; font-size= -adjust: 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: n= ormal; font-weight: normal; font-size: 10pt; line-height: normal; font-size= -adjust: 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<=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: <the actual data length> (explicitly set)<br> connection: keep alive (implicitly set)<br> content-type: application/x-www-form-urlencoded (explicitly set)<br> <no transfer-encoding parameter set><br> <br> and the actual data sent does not have the chunked formating, as below:<br> <br> 3333223 cdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96<=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 href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a> and include in the body of the message "signoff KVM-INTEREST". Fo= r general help, send email to <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</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 href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a> and include in the body of the message "signoff KVM-INTEREST". For general help, send ema= il to <a href=3D"mailto:[email protected]" target=3D"_blank">listserv@jav= a.sun.com</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 href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a> and include in the body of the message "signoff KVM-INTEREST". For general help, send ema= il to <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= n.com</a> and include in the body of the message "help". </blockquote> <br> </div></div><font color=3D"#888888"><pre cols=3D"72">--=20 /************************** * Roger F. H=F6sl * ... **************************/</pre> </font></div><div><div></div><div class=3D"h5"> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=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 href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a> and include in the body of the message "signoff KVM-INTEREST". For general help, send em= ail to <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= n.com</a> and include in the body of the message "help". </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>ricardo]sch= olz<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". --001517573d7823eb15046d051a56--