sending 404 responses for epty objects.

Maxim Dounin mdounin at
Thu Dec 11 14:30:11 UTC 2014


On Thu, Dec 11, 2014 at 03:54:25AM -0500, Cord Beermann wrote:

> Hello,
> Due to issues with a backend beyond my influence i need to fix this with
> Nginx.
> Root-Cause: A CMS generates empty files on a filesystem which will be later
> filled with content. However: those files are there for some time with 0
> bytes
> and will be served with 200 through a chain of a caching Nginx and a caching
> CDN.
> User --> CDN --> Caching Nginx (SlowFS) --> Serving Nginx --> Filesystem.
> The Backend-Filesystem is served by a Nginx. Solution could be to serve a
> 404
> for all empty files.

Please note that this is _not_ a solution, as at some point files 
will be partially filled with content, and testing that the size 
isn't 0 won't help.  Rather, it's a workaround which hides the 
problem in some cases.

The only _solution_ I see is to fix backend to update files 
atomically - e.g., write to a temporaty file, and then rename() 
it to a real name.

> I tried with $sent_http_content_length, but it seems to
> be empty in the location where i would need it. Is it possible to use some
> kind of 'test -s' on the file to decide when to send a 404?

This is something possible with embedded perl (and lua, as already 

> I also tried to tackle it in the caching SlowFS-Nginx, by using
> $upstream_http_content_length in if or map-statements [1]. I can see
> $upstream_http_content_length set in an X-Debug-Header i added, but can't
> get
> it to work to use it to act on it.
> 	if ($upstream_http_content_length = 0) {
> 	  return 404;
> 	}

This is not going to work as "if" will be executed before the 
request is sent to the upstream server.

Maxim Dounin

More information about the nginx mailing list