A better approach, if you are just going to hook up “data” to “write()” and “close” to “end()”:
// 0.3.x style
fs.createReadStream(filename, {
'bufferSize': 4 * 1024
}).pipe(response)
// 0.2.x style
sys.pump(fs.createReadStream(filename, {
'bufferSize': 4 * 1024
}), response)
The read.pipe(write) or sys.pump(read, write) approach has the benefit of also adding flow control. So, if the write stream cannot accept data as quickly, it’ll tell the read stream to back off, so as to minimize the amount of data getting buffered in memory.
The flags:"r" and mode:0666 are implied by the fact that it is a FileReadStream. The binary encoding is deprecated — if an encoding is not specified, it’ll just work with the raw data buffers.
Also, you could add some other goodies that will make your file serving a whole lot slicker:
- Sniff for
req.headers.rangeand see if it matches a string like/bytes=([0-9]+)-([0-9]+)/. If so, you want to just stream from that start to end location. (Missing number means 0 or “the end”.) - Hash the inode and creation time from the stat() call into an ETag header. If you get a request header with “if-none-match” matching that header, send back a
304 Not Modified. - Check the
if-modified-sinceheader against themtimedate on the stat object. 304 if it wasn’t modified since the date provided.
Also, in general, if you can, send a Content-Length header. (You’re stat-ing the file, so you should have this.)