Alan Gutierrez

I’m hacking on the mod_proxy module in Apache 2.2. I’ve got a pushlet application that for reasons of consistancy must be proxied through Apache. Unfortunately, mod_proxy does not work correctly when the chunked transfer encoding is used in a pushlet fashion.

Apache wants to buffer the upstream request, at least enough to fill an 8k packet. When it gets a chunk it writes it to an 8k buffer. If the buffer is not filled, it will wait until the next chunk arrives before flushing the buffer.

When a pushlet application is sending small chunks, in my case a couple dozen bytes, then the client, which is expecting these chunks as they are generated, is going to recieve the chunks as a much bigger chunk. My application generates its chunks intermitantly, so the client will not see a data except, oh, every other day.

There’s a fix already in place. It doesn’t fix my application. According to the bugzilla entry, it will read the upstream with a non-blocking read, and if the read returns EAGAIN, indicating that the read would block, the 8k buffer is flushed.

It’s broken in two ways. First, somewhere the code path, from the proxy call, to some logging calls, to the raw socket read, a condition swallows the EAGAIN and returns success.

More importantly, the headers, when read, are always read with a blocking read. The non-blocking mode is only used for the body. Since my application sends full chunks, it is the read of the headers that will block, and the mod_proxy code waits and waits.

I’ve gone and added a kludge to send packets as is. The 8k buffering is bad news for my application, since if I want to send a larger chunk, I’ll do that from my pushlet server code. I’ve already considered the chunk size when the chunk was formed. I don’t want mod_proxy to muck with it.

Perhaps I should read the HTTP 1.1 protocol to determine if I can make such petulant demands.