Tag: Tomcat

Tomcat, WebSockets, HTML5, jWebSockets, JSR-340, JSON and more

On my recent excursion into non-blocking servers I came across Comet, server push technologies and then Web Sockets. I was late arriving at the Comet party, but I think I have arrived at the Web Sockets party just in time. The final standard is still being evovled and at the time of writing, the only browser supporting it by default is Chrome. So to get started, I had a look at what was around. Initially, I wasn't going to write a blog article about it, I just wanted to learn about this new thing. My only requirement was that the server implementation was Java based. The reason is simple - my entire technology stack is based on Java EE and I want to be able to integrate all my existing stuff into any new server, without the need for an integration bus. I like being able to drop a JAR file from one project into another one and to be up and running immediately. So I had a quick look at jWebSockets, Grizzly (Glassfish), Jetty and Caucho's Resin. All similar, yet all somewhat different. Most different, was jWebSockets, because they have gone to the extent of building their own server, instead of basing their solution on an existing server. I had a good long rant about that kind of thing when I blogged about node.js, so I won't start again. But jWebSockets has a real issue to face in the coming years. JSR-340 talks about support for web technologies based…

Read more

Transfer-Encoding: chunked

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…

Read more