First off -- a lot of us where I work really like the Kyocera phone (including me). Unfortunately, here's another very bad bug when using INetLib that affects only the Kyocera phone. The bug occurs with both simple PQA apps and simple C/C++ apps that use INetLib (including Palm's sample INetLow app). In other words, this very bad bug is not the fault of the programmer as so many turn out to be (grin). The bug is simply this: you cannot send more than about 488 bytes in an INetLib HTTP request (the number of bytes may differ under various circumstances, but our tests seem to always be 488 bytes). If you try to post more, the HTTP header is corrupted either by the Proxy Server or by the Kyocera phone. We used Mocha PPP and a packet sniffer to see what packets were being sent by the phone and what packets were received by the server. We found that the POST destination URL was corrupted in a repeatable way when the posted data was more than 488 bytes. As an example, if we posted 488 bytes to an address like http://disp.ae.net/ae/dispatcher.dll, the HTTP header received by the server for the post request began with "POST /ae/dispatcher.dll". That is perfect. But if we posted 489 bytes, the post request began with "POST /ae/dispatcher.dllhttp://disp.ae.net/ae/dispatcher.dll";. As you can see the destination URL was corrupted by having the full URL appended to it. When we used Mocha PPP to look at the raw data being sent by the phone, we found that the phone sends 536 bytes per packet (this includes posted data plus a binary header). It appeared that as long as the post request fit in one 536 byte packet, it all worked, but if the phone required two or more packets to send the post request then the destination URL was corrupted either by the phone or by the Proxy Server. We were able to partially overcome the problem by appending a '?' to the URL. This made the corrupted destination URL look like "POST /ae/dispatcher.dll?http://disp.ae.net/ae/dispatcher.dll"; which the server parsed as the proper destination URL, plus some additional posted data. But this doesn't work with secure HTTPS addresses apparently because the corrupted header is encrypted and perhaps the corruption breaks the encryption -- we're not sure yet. If this problem lies with the phone, then likely the proxy server could be changed to overcome the problem which would be a far better solution than forcing an upgrade of every phone out there. On the other hand, the bug may actually be in the proxy server and only the Kyocera phone may be causing it to happen. We tried all of the Palm proxy servers (206.112.114.82, 206.112.114.83, and the default hard reset 63.<whatever>... address) and they all had the same problem. If anyone at Palm or Kyocera reads this message and forwards it on to someone to look into the problem, could you please email me privately and let me know? Otherwise, I'll probably end up making a pest of myself until I know this bug has registered on someone's radar. Thanks. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
