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.range
and 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-since
header against the mtime
date 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.)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…