Compression is already being used. (The client accepts gzip encoding.)
But unless I'm missing something, there should never be a reason for the server to use chunked encoding. Right? The server always knows the size of the packet being returned, so it can always set the buffersize and content length. Am I missing something?
In any case, the reduced performance from chunked encoding is less important to me right now than the fact that Chrome seems to find the chunked encoding being returned by OpenFire to be invalid in some way. I've seen several references to this online where some servers are not properly terminating chunks with CRLF. Other browsers seem tolerant of this, but Chrome refuses to adapt, apparently.
As it stands, even though my packets are modest in length, they can bunch up, and over BOSH, these get grouped together by OpenFire and returned within a single HTTP request, and this larger packet (30 to 60K) containing 2 or 3 messages gets chunked encoding.
