UrlBlogGrey

A customer issue I am dealing with at work involves the use of HTTP 1.1 chunked transfer-encoding on the BEA Weblogic 8.1 application server (SP3, in this case). Chunked transfers offer a very efficient method of transferring large amounts of data since they allow the payload to be broken up into manageable chunks of data. The alternative is to transfer the entire payload in a single message (expensive since it needs to be buffered in memory), or programmatically divide the payload into pieces for sequential transmission (difficult, requires a non-standard protocol between receiver and sender).

So, HTTP 1.1. chunked encoding is being used by our product to transfer large files between the client and server. It should work fine, except that it relies on the application server/web server to have implemented the HTTP 1.1 protocol correctly. I've come to learn that BEA's Weblogic 8.1 application server has the poorest implementation, by far.

The most aggregious offense is that client requests using a fixed content-length (alternative to chunked transfer-encodings) will occasionally receive a response that uses chunked transfer-encoding. This would be like asking someone to call you back on the phone, but instead they write you a letter. Fortunately, our client doesn't make much of a distinction between the encoding used; rather, it just cares that a response is provided.

Additionally, there is a bug in Weblogic 8.1 (S-31186) where use of chunked transfers in a cluster will result in buffering of the HTTP response. Buffering of communications for an undetermined amount of time doesn't work for real-time applications like ours. It appears that disabling the use of chunked transfers altogether in the server's config.xml might solve the problem, but that's a horrible compromise to make.

However, if a system sits between the client and application server, it's possible that the system would be confused by the mismatch in encodings. I've noticed that when an Apache HTTP server is configured as a reverse-proxy (a common setup that limits web traffic to a DMZ) a chunked response can be buffered by the HTTP server for as long as 9 minutes. This is long enough for the client to time-out and disconnect under the assumption that the server is unreachable. This has resulted in more than a few headaches as I've tried to remedy the situation.

So, I have one point to make: protocols and standards exist to make communication easier. Deviation from protocols (i.e. slang) results in conversations that can be difficult to understand. Companies such as BEA wouldn't write a press-release composed in slang. So, why would they release their core product with a half-ass implementation of a communication protocol? People are building products and basing their success on the quality of products like BEA Weblogic. How about a little professionalism? Please?