Secure connection failed on Firefox

Maxim Dounin mdounin at
Sat Oct 7 13:16:08 UTC 2017


On Sat, Oct 07, 2017 at 02:14:26AM -0400, joseph-pg wrote:


> Looks like it's the culprit. It happens at random times for a few seconds,
> so it's rather difficult to reproduce.
> Here's the output of the debug log when the error occured (I was wrong,
> weird things do happen here, eg. an entry with alert flag below):


> > 2017/10/07 11:28:05 [debug] 18764#15836: *15 cached open file:
> path/to/website/index.html, fd:560, c:2, e:0, u:16


> > 2017/10/07 11:28:05 [debug] 18764#15836: *15 http copy filter:
> "/index.html?somequerystring"
> > 2017/10/07 11:28:05 [debug] 18764#15836: *15 malloc:
> 00000287AAEE0290:4096
> > 2017/10/07 11:28:05 [alert] 18764#15836: *15 ReadFile() read only 993 of
> 1013 from "path/to/website/index.html" while sending response to client,
> client:, server: my-internaldomain, request: "GET
> /?somequerystring HTTP/2.0", host: "my-internaldomain"

The message suggests that the file in question was non-atomically 
modified while being served.  It is expected that such a 
modification will lead to a fatal error if nginx will be able to 
detect the problem.  If it won't, likely the client will get a 
garbage with a mix of original and new contents of the file.

The only safe approach is to modify files atomically, that is, 
create a new file and then use mv (the rename() syscall) to move 
it atomically to the appropriate place.  It might not be trivial 
or even possible to do this correctly on Windows though[1].

Additionally, it looks like you are using open_file_cache.  It is 
actually a very bad idea if you modify files in-place, as it 
greatly expands the race window between opening and stat()'ing the 
file and serving its contents.  Remove open_file_cache from the 
configuration unless you are sure all file modifications are 


Maxim Dounin

More information about the nginx mailing list