On Sun, Jun 5, 2011 at 8:16 PM, William A. Rowe Jr. <wrowe@xxxxxxxxxxxxx> wrote: > On 6/5/2011 12:31 PM, Xavier Noria wrote: > > httpd (conditionally) handles the chunking... the app generator's > chunking is never used. ÂWhat *module* is installed in httpd? ÂI'm > not familiar with the above. > > Only the entry point to httpd, e.g. mod_proxy, mod_wl, mod_ws, mod_jk > mod_cgi or whatnot should ever dechunk. ÂThe response body must pass > through httpd without any protocol (chunking) or headers. Ah, interesting. Phusion Passenger is an Apache module itself: http://www.modrails.com/ Passenger is the most used solution for production deployments in Ruby on Rails nowadays. So I understand from your reply that httpd is the only one resposible for chunked responses, compressed or otherwise. Is that correct? So a module like Passenger is expected to dechunk and pass the body to httpd? As of this writing chunked responses are passing through Apache if compression is not involved. Guess that works by luck, but it is still not playing by the rules? If whether the response has to be streamed or not is decided by the application, which is the proper way to force httpd to stream, and eventually also compress? Use case is flushing the HEAD of HTML documents for dynamic pages whose content generation is costly. So, while content is being produced, the client is already fetching assets. -- fxn PS: Streaming is a new feature to be out with Rails 3.1, we are exploring production setups that play well with compression. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx