Symsource

In a recent project we were creating a funky new Twitter client for Sony-Ericsson MIDP handsets. Sounds dull, but there were some cool features of this product which made it much more interesting than it sounds (no I can’t elaborate :-).

Part of this was upload of pictures to Twitpic. “Great”, we thought, “Twitpic - simple URL-based REST API. Should be easy enough”. As it turned out, not as simple as originally anticipated.

The problem is a mis-match between the behaviour of the Sony-Ericsson MIDP HTTP stack and the needs of the Twitpic server.

The Twitpic server requires a Content-Length header to be included, or else your picture post is rejected. The Sony-Ericsson HTTP stack, however, adopts HTTP/1.1 chunked encoding for any payload over a few kilobytes…. and HTTP/1.1 chunked encoding doesn’t supply a Content-Length header. Argh!
All attempts to explicitly set the Content-Length header in MIDP (via HTTPConnection::setRequestProperty("Content-Length", length) were soundly ignored by the Sony-Ericsson devices.

Double Argh!

The solution? Painful, but for Twitpic posts we use a socket connection and mock-up the HTTP communication, headers etc. including the Content-Length header. This meant more work, but in addition meant the application needed to be signed (i.e. Java Verified) in order for Twitpic to work - socket connections to port 80 require a trusted third party domain.

So, problem solved - in the end without any schedule impact - but with some consequences for the product deployment.