The J2ME HTTPConnection which comes with MIDP lets you make HTTP requests to your server. It doesn’t do much at a high level, for example the API doesn’t have methods like addCookie() – you need to manually add them with a request header. But the implementation is clever enough to turn any request body which is greater than around 2Kb into a chunked request.
With HTTP 1.0, the request had to contain a header called Content-Length which told the server how many bytes to read off the input stream when reading the body. HTTP 1.1 introduced the Transfer-Encoding header, which lets the client omit the Content-Length header, and instead create chunks of request body, which optimises the upload meaning that a) the server can start processing before it has everything, and b) more importantly for J2ME where memory might be a valuable resource, it lets the client send a bit of the request, free up that allocated memory and then send some more of the request.
For a POST request, with no chunking, the headers and body might look like this:
POST /log.jsp HTTP/1.1 User-Agent: Mozilla/4.0 (maxant J2ME Client) Accept: text/html,application/xhtml+xml,application/xml Content-Type: application/x-www-form-urlencoded Content-Length: 51 Host: wwwchaseamatecom:8089 problem=Failed%20to%20get%20installation%20response
Chunked, that becomes:
POST /ota/addInstallation.jsp HTTP/1.1 User-Agent: Mozilla/4.0 (maxant J2ME Client) Accept: text/html,application/xhtml+xml,application/xml Content-Type: application/x-www-form-urlencoded Host: wwwchaseamatecom:8089 Transfer-Encoding: chunked problem=Failed%20to%20get%20installation%20response
You’ll notice that the body of the second example, "problem=…" doesn’t contain chunk headers (search Wikipedia for chunking to see an example). The reason is that I copied that text out of the TCP/IP Monitor in Eclipse 3.5 and it seems kind enough to hide that information and simply show you the unchunked body. Not great if you aren’t expecting that, somewhat useful none the less.
Anyway, about time I got to the point of this blog article. Any version of Tomcat before 5.5.28 or 6.0.21 (ie. the latest versions at the time of writing!) had a nasty bug in them whereby POST requests did NOT get the body parsed and put into request.getParameter(String) or request.getQueryString(). Very nasty indeed for J2ME developers. I trawled the internet and found people were having problems from around 2002 when HTTP 1.1 became available in J2ME. Only with the following bug fix has this finally been corrected on Tomcat, some 8 years later.
Work arounds included using Apache to put together the chunks before sending the request on to Tomcat, or manually splitting the request on the device, into small chunks and upload each one and then joining them together at the end – what a load of work to have to do!
I’m working with an old 5.5.9 Tomcat installation and have just upgraded it to 5.5.28 to fix this problem.
However before I found this bug report I did consider creating a filter and configuring it in my web.xml. The idea was that the filter would read the request body, URL decode it, unlock the requests parameter map (Catalina has a lockable map which is locked after parsing the request), and put the request bodies request parameters into the map. Something like this:
I wasted hours because of this rubbish bug. The problem is that its full of red herrings, making you think for example that because the monitor shows the request body unchunked, that the device isn’t chunking the body properly. The web is also full of very old posts related to servers not being HTTP 1.1 compatible. And there are lots of work arounds which people went to the effort of because they had no other choice until most recently. So hopefully if you have had chunking problems with J2ME, you found this article without too much hassle!
Copyright (c) 2010 Ant Kutschera