Flush FastCGI response early vs. GZIP

Thu Jul 12 12:36:21 UTC 2012

Sending the first few kilobytes of an HTML page to the client as early
as possible enables the client to download stylesheets without having
to wait for the whole HTML document (which might require database
queries and can therefore be relatively slow). Loading the stylesheets
early is important because the browser blocks rendering on
stylesheets. Details are available here:
http://calendar.perfplanet.com/2009/progressive-rendering-via-multiple-flushes/

So what I would like to do is: 1) Send the <head> element with its
stylesheet references to the client immediately. 2) Afterwards query
the database and generate the whole HTML page and send it to the
client. Meanwhile the client had a chance to already fetch the
stylesheets.

My problem is that nginx buffers FastCGI responses. I can only flush
the first few kilobytes early if I configure nginx to use very small
FastCGI buffers:

fastcgi_buffer_size 2k;

This does not seem to be a good idea in general because it might cause
the "upstream sent too big header" error in other scripts.
Additionally, the GZIP module has its own buffers that I'd have to
shrink as well (which does not sound like a great idea in general).

Is it possible to handle this issue with an nginx feature that I have
overlooked?

My idea would be a new internal header "X-Accel-Flush: [offset]" that
FastCGI apps could send to nginx to flush the partial response after
[offset] bytes. The GZIP module should obey this header, too (instead
of continuing to buffer the response).

Thanks
Steffen