Its about stale data in the client. If the HTTP client request an exact byte-range, then this particular byte-range was chosen because of a reason, like the moov atom in mp4 files; the header of a pdf file or similar stuff (depending on the content-type). Here is the problem: when the client reads the first bytes of the PDF today, and the user scrolls down tomorrow (adobe reader makes heavy use of range requests iirc), the pdf on the server needs to be exactly the same (bit for bit). If its not, the byte-range request must not be successful, otherwise the application will get corrupt data (how can the byte offset still be the same with the file from yesterday if the content changed on the server). This is the reason why the HTTP server needs to validate the client-side cache with things like filemtime. If we can't validate the client cache, we can't serve 206 partial content. In case of dynamic content we have no way to do this (theoretically it would be doable with etag stro
ng validation, but nginx doesn't support it and your application surely doesn't either).

Iirc, (please correct me if I'm wrong), nginx, when configured as a caching reverse proxy serves 206 only when the object is already in the local nginx cache. If its not there, full file will be served.


Also read HTTP/1.1 specs in [1].


Can you tell us more about your use case? Is your dynamic content really that big? Maybe you are approaching this from the wrong side, x-accel-redirect can probably help here, as Ensiferous already posted.



[1] http://tools.ietf.org/html/rfc2616#section-10.2.7
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx