I am having trouble streaming HTTP tunneled video through nginx reverse proxy. My frontend server is running nginx 0.7.67 and a backend server sources a live video feed (RTSP wrapped in HTTP, mime application/x-rtsp-tunneled).

This is the video tag in the webpage:
[code]
<embed src="redirect.mov"
width="720"
height="480"
qtsrc="rtsp://frontend/path/stream"
autoplay="true"
controller="true"
target="myself"
PLUGINSPAGE="http://www.apple.com/quicktime/download/">
</embed>
[/code]
The quicktime browser plugin requests redirect.mov from the streaming server. Then the streaming server and the browser plugin use an HTTP tunnel for wrapping the actual RTSP stream (.../path/stream).

I can access the video stream fine using any web browser if I get it directly from the backend. However, behind nginx reverse proxy, the stream won't play. Here's my nginx configuration:
[code]
server {
listen 80;
server_name frontend;
location / {
proxy_pass http://backend;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
}
}
[/code]
Nginx starts loading http://backend/path/stream when the client requests http://frontend/path/stream. However, it stops shortly thereafter.

The quicktime user agent sends a POST request for the stream URL with content-length set to 32767. This request only comes with 280 or so bytes of body data. I guess the UA claims a huge content-length just to keep the pipe open. Now, nginx waits on the client connection for the remaining 32500 bytes, i.e. it does not forward the first 280 bytes to the backend streaming server which would have responded and triggered more data from the client but since the client won't receive a response to its first 280 bytes of "in-band" request the quicktime user agent times out and shuts down the connection. End of stream...

Is it possible to "magically" configure nginx to transparently forward request data and response data immediately when they arrive?