Java Development

[dbb]

I have a MIDlet that works on other devices. It does an HTTP POST of binary data to my server.  It follows the normal Connector.open(), HttpConnection.setRequestMethod(), HttpConnection.setRequestProperty(), HttpConnection.openDataOutputStream(), DataOutputStream.write(), DataOutputStream.flush(), HttpConnection.getResponseCode() sequence.   When running the mobile application on the JDE/MDS, the post data does not appear on the server, even though I can see that the output stream writing of the HTTP connection is executed; in the MDS log, it says that the entity connection section of the HTTP request is empty:

<2009-03-17 16:59:51.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 876357923, HTTPTRANSMISSION = [Entity Content Section]: 0 bytes>

I've tried it both with the content type set to "application/octet-stream" and skipped with no difference.  Are there restrictions on the content type when making a post from BlackBerry?  Is there anything special about doing an HTTP POST of binary content on BlackBerry?  Would the content-length header be required?  Apologies if I've missed some already documented information.  I've seen other posts about empty HTTP POST content, but none seemed to be relevant to my case.  I've been able to get HTTP GET working, it's the posting of binary data I'm having problems with.

I'm using JDE 4.0.2 so as to target all MIDP 2.0 devices.

[peter_strange]

I'm not familiar with the MIDLET environment, and have only posted text data, but two quick questions that might help:

1) Have set the Content Length, for example:

<connection>.setRequestProperty("Content-Length", Integer.toString(postBytesLength));

2) Does it work with Text data?

[dbb]

I have created a test program that can post binary data, but I still can't get my real program to. The code seems extremely similar to me but in the real program MDS does not see the post data. I've googled plenty of similar issues and believe that I've applied all the reasonable suggestions.

MDS log of data received from device for test program

<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = [Transmission Line Section]:>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = POST /om/httpreqdecode HTTP/1.1>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = [Headers Section]: 3 headers>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = Host:localhost:8090>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = Content-Length:208>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = User-Agent:BlackBerry7290>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = [Parameters Section]: 0 parameters>
<2009-03-20 10:39:30.874 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920299, HTTPTRANSMISSION = [Entity Content Section]: 208 bytes>

MDS log of data received from device for real program

<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = [Transmission Line Section]:>
<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = POST /om/devsync HTTP/1.1>
<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = [Headers Section]: 2 headers>
<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = Host:localhost:8090>
<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = User-Agent:BlackBerry7290>
<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = [Parameters Section]: 0 parameters>
<2009-03-20 10:40:14.499 PDT>:[130]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1613920300, HTTPTRANSMISSION = [Entity Content Section]: 0 bytes>

The Content-Length header in the test program log is manufactured by the simulator -- my code does not explicitly create it.  Note that it does not appear in the log for the real program.

My real data is 208 bytes for the test case, so in the test program I made up 208 dummy bytes to send to a servlet on the same server that just sends me back a message saying what it's received. In both cases the code gets an HttpConnection using Connector.open( "the-url", Connector.READ_WRITE, true ), sets the request method to POST, sets the user agent, calls HttpConnection.openDataOutputStream(), writes the post data, calls DataOutputStream.flush(), followed by HttpConnection.getResponseCode(); there are multiple calls to another thread which updates a ProgressGauge. (I have tried commenting out the UI update - it doesn't change the behavior.) In the test case, everything runs and MDS sees the post data. In my real program, the flush of the post output stream hangs (or the the getResponseCode() call times out if the flush is commented out). Can anybody suggest what might be causing this behavior or where to go look to get some clues?

Thanks.

[dbb]

I did also try explicitly setting the content length header before opening the output stream.  There was no difference in the MDS not seeing any content bytes from the device.  Interestingly, the MDS stripped that header when sending the request on to the server.

[MSohm]

The obvious question here is what is different between your test application and real application?  I also recommend enabling verbose logging in the MDS Simulator to try and get a better idea on what is being sent.

How To - Enable HTTP and HTML logging in the BlackBerry MDS Simulator
Article Number: DB-00156

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800792/801079/How_To_...

[dbb]

Yes, I already had the MDS logging configuration file set to the values referenced in that article.  (The only other changes I'd made were to change ports 8080 and 8091 to resolve port conflicts on with the pre-existing (J2EE) web server on my development PC.)  The console logging is set to 5 and the file logging is set to 4, but the output for the section of interest is identical (which is more verbose?).

I agree that the obvious question is what's different between the test and real application.  To that end, I've temporarily turned my real app into a bit of a Frankenstein's monster by grafting the test app into it.  I am attempting to whittle away the differences bit-by-bit.  I was unable to discern anything useful from the log outside of the fact that in the test code it was able to read all of the POST data bytes:

file log when post data is read:

<2009-03-26 13:30:59.296 PDT>:[101]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: JobRunner-0 started>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = [Transmission Line Section]:>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = POST /om/devsync HTTP/1.1>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = [Headers Section]: 3 headers>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = Host:diamond:8090>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = Content-Length:208>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = User-Agent:BlackBerry7290>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = [Parameters Section]: 0 parameters>
<2009-03-26 13:30:59.296 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1720667107, HTTPTRANSMISSION = [Entity Content Section]: 208 bytes>

and no POST data bytes were read in the real code:

file log when post data not read (console log level 5 is identical):

<2009-03-26 13:56:23.250 PDT>:[101]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: JobRunner-0 started>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = [Transmission Line Section]:>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = POST /om/devsync HTTP/1.1>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = [Headers Section]: 2 headers>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = Host:diamond:8090>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = User-Agent:BlackBerry7290>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = [Parameters Section]: 0 parameters>
<2009-03-26 13:56:23.265 PDT>:[102]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVICEPIN = 2100000a, CONNECTIONID = 499107543, HTTPTRANSMISSION = [Entity Content Section]: 0 bytes>

I'm not seeing any significant difference between the two except for that fact that in one case the POST bytes are seen and in the other not.  The Content-Length header is not generated by my code, so apparently it's generated by the device simulator.

This process is slowed down quite a bit by the simulator from time-to-time deciding to hang the thread that does the HTTP I/O (on the POST flush() call, or getResponseCode() if no flush() call) when (it appears) to me that I've made no change that would affect it (for example, renaming a method).  I have the code closing streams and connections as mentioned in:

How To - Close connections
Article Number: DB-00530
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800451/800563/How_To_...

Also, I've looked at the forum post entitled Weird Connection Problem at http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&message.id=4888 which would seem to be related to that issue.  For a while I was trying to use the 4.6.0 simulator to make some progress, but then suddenly it seemed that the 4.6.0 MDS didn't notice at all then the device simulator tried to open a connection.  In the 4.0.2 simulator, it seems that sometimes the condition gets cleared out after shutting down the device simulator, erasing the simulator's file system and NVRAM (from the JDE File menu), and restarting the MDS simulator. (I know this is not the issue of this forum post; I only mention it because it's slowing me down a lot in trying to narrow down the differences between the working and non-working cases.)

[dbb]

[Small addendum to last post.]

On the HTTP POST OutputStream.flush issue, I do have a separate thread that updates a progress gauge and does no UI itself.  I do find it odd that in the simulator, when the test case POST does get through, I don't get the confirmation question about whether I want to grant the application access to the given URL.

[dbb]

A little more data about the simulator hanging on the OutputStream.flush call of the test code that can in fact write the POST data:

In the debug pane of the JDE, when the device simulator hits the flush call:

Exit net_rim_sdk_simulationSB(66)

It seems to happen consistently there when it hangs and close to the beginning of the program on a successful run.  Why would that be?

The MDS log in this case shows that the server returned the expected (110 in this case) bytes, but with the device simulator hanging on the flush call, the device simulator eventually times out:

<2009-03-26 17:36:41.218 PDT>:[390]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = QueueSize, DEVICEPIN = 2100000a, SendingQueue = 0>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = [Transmission Line Section]:>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = HTTP/1.1 200 OK>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = [Headers Section]: 5 headers>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = Content-Type:application/x-orgmob-devsync>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = Connection:close>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = Date:Fri, 27 Mar 2009 00:36:41 GMT>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = Server:Sun Java System Application Server 9.1_02>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = X-Powered-By:Servlet/2.5>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = [Parameters Section]: 0 parameters>
<2009-03-26 17:36:41.218 PDT>:[391]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, HTTPTRANSMISSION = [Entity Content Section]: 110 bytes>
<2009-03-26 17:36:41.234 PDT>:[394]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: JobRunner-7 stopping>
<2009-03-26 17:36:41.234 PDT>:[395]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: JobRunner-7 stopped>
<2009-03-26 17:36:41.234 PDT>:[396]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Sending, TAG = 348717066, DEVICEPIN = 2100000a, VERSION = 16, CONNECTIONID = 1853341086, SEQUENCE = 0, TYPE = DATA, SIZE = 225>
<2009-03-26 17:36:41.234 PDT>:[397]:<MDS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Finished JobRunner: JobRunner-7, available threads in JobPool = 10>
<2009-03-26 17:36:41.265 PDT>:[400]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Sending, TAG = 348717067, DEVICEPIN = 2100000a, VERSION = 16, CONNECTIONID = 1853341086, SEQUENCE = 1, TYPE = DISCONNECT-ORDER, SIZE = 0>
<2009-03-26 17:36:41.265 PDT>:[401]:<MDS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Device connections: AVG latency (msecs)47>
<2009-03-26 17:36:41.296 PDT>:[402]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: ConnectionsInputStreamesReader0-JobRunner-7 stopping>
<2009-03-26 17:36:41.296 PDT>:[403]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: ConnectionsInputStreamesReader0-JobRunner-7 stopped>
<2009-03-26 17:36:41.296 PDT>:[404]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedReceivingQueue, DEVICEPIN:CONNECTIONID = 2100000a:1853341086, QueueSize = 0>
<2009-03-26 17:38:40.312 PDT>:[405]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Receiving, TAG = -1423920386, DEVICEPIN = 2100000a, VERSION = 16, CONNECTIONID = 1853341086, SEQUENCE = 1, TYPE = DISCONNECT-ORDER, SIZE = 0>
<2009-03-26 17:38:40.421 PDT>:[406]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedSendingQueue, DEVICEPIN = 2100000a, CONNECTIONID = 1853341086, QueueSize = 1>
<2009-03-26 17:38:40.421 PDT>:[407]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedReceivingQueue, DEVICEPIN:CONNECTIONID = 2100000a:1853341086, QueueSize = 0>
<2009-03-26 17:38:40.453 PDT>:[408]:<MDS_MDS>:<DEBUG>:<LAYER = IPPP, ERRORMSG = Invalid, DEVICEPIN:CONNECTIONID = 2100000a:1853341086, SEQUENCE = 1, Information = Received Packet for a timed out connection>
<2009-03-26 17:38:40.984 PDT>:[409]:<MDS_MDS>:<DEBUG>:<LAYER = MDP, Receiving ACK for not existing datagram>

Note: this is still the flush timeout issue in the test code; I'm still narrowing down the differences between the test and real code to try and see what the trigger for the POST stream being discarded is in the real program.

[dbb · Accepted solution]

I've found what triggers this behavior in the simulators.  I had a bug in my code which caused it to unintentionally (although permitted by RFC 2616) write an HTTP header with an empty string for a value.  I would say that this then triggered a bug in the the device simulator which then swallowed that header (which explains why the header was not shown in the MDS log) and did not pass on the output stream with the HTTP POST data.

An abstraction of the code triggering the bug looks like:

// ...
String locale = functionThatReturnsEmptyString();
// ...
HttpConnection hc = (HttpConnection)Connector.open( 
  "http://foo.com/bar", Connector.READ_WRITE, true );
hc.setRequestMethod( HttpConnection.POST );
hc.setRequestProperty( "User-Agent", "BlackBerry7290" );
// Content-Language header value is empty string!
// and apparently never makes it from device simulator to
// MDS simulator
hc.setRequestProperty( "Content-Language", locale ); 
// ...
byte[] ba = dataToPostViaHttp(); // my binary POST data
DataOutputStream dos = hc.openDataOutputStream();
dos.write( ba, 0, ba.length );
// data not truly flushed due to HTTP header with empty string for value
dos.flush(); 
int rc = hc.getResponseCode();
DataInputStream dis = hc.openDataInputStream();
// ...

RFC 2616 at http://www.ietf.org/rfc/rfc2616.txt is pretty clear that an empty value for an HTTP header is legal in HTTP:

2 Notational Conventions and Generic Grammar

2.1 Augmented BNF

   All of the mechanisms specified in this document are described in
   both prose and an augmented Backus-Naur Form (BNF) similar to that
   used by RFC 822 [9]. Implementors will need to be familiar with the
   notation in order to understand this specification. The augmented BNF
   includes the following constructs:

   ...

   *rule
      The character "*" preceding an element indicates repetition. The
      full form is "<n>*<m>element" indicating at least <n> and at most
      <m> occurrences of element. Default values are 0 and infinity so
      that "*(element)" allows any number, including zero; "1*element"
      requires at least one; and "1*2element" allows one or two.

   [rule]
      Square brackets enclose optional elements; "[foo bar]" is
      equivalent to "*1(foo bar)".



...

4 HTTP Message

4.1 Message Types

   HTTP messages consist of requests from client to server and responses
   from server to client.

       HTTP-message   = Request | Response     ; HTTP/1.1 messages

...

        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line      = Request-Line | Status-Line
...

4.2 Message Headers

   HTTP header fields, which include general-header (section 4.5),
   request-header (section 5.3), response-header (section 6.2), and
   entity-header (section 7.1) fields, follow the same generic format as
   that given in Section 3.1 of RFC 822 [9]. Each header field consists
   of a name followed by a colon (":") and the field value. ...

       message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>

[Note that the "field-value" is explicitly optional with the square brackets in the "message-header" production and that the "*" notation is used in the "field-value" production indicating that it may consist of explicitly zero instances of "field-content".]

So, I've got that part of my code working now, but I'd say that this indicates a bug in the simulator software and perhaps handset in the handset software as well (haven't tried that).

[MSohm]

Thank you for posting all of this detailed information.  I am able to reproduce this issue and have sent it to our development team.  In my tests the empty header value did work on a real BlackBerry handheld, but failed in the BlackBerry Simulator.