Add support for multipart/byterange responses #114
Conversation
| stream = fs.createReadStream(path, range) | ||
| stream.on('error', next) | ||
| stream.on('end', function onpartend () { process.nextTick(next) }) | ||
| if (!idx) self.emit('stream', stream) |
There was a problem hiding this comment.
Not sure how you want to handle this. I'm creating a new read stream for every range/part so right now I'm only emitting the 'stream' event on the first iteration. I could emit this event on every iteration, but I feel like that might be confusing for a developer using this library since they would end up seeing this event get triggered N times, but the 'end' event would only get emitted once.
* Improve detection for fs.createReadStream's `autoClose` option * SuperTest (which uses Formidable) doesn't seem to be able to correctly parse multipart/byteranges bodies so I've come up with a little hack.
It certainly doesn't locally or on TravisCI, so...
of the correct `EBADF` error code because of a bug in libuv: * nodejs/node#3718 * libuv/libuv#613
| // adjust for requested range | ||
| offset += ranges[0].start | ||
| len = ranges[0].end - ranges[0].start + 1 | ||
| } else if (ranges.length > 1) { |
There was a problem hiding this comment.
Maybe this path should be restricted to some maximum array length. It could be made configurable but would default to say 10.
|
@dougwilson I'd greatly appreciate a review on this :) I promise I won't make any more commits to this branch. I think I finally got everything nailed down with regards to node < 0.10. |
|
Closing this because I'm working on something better. Will get a new PR up soon. |
|
Sweet. I'm sorry I haven't really sat down to review it, but I have definitely been opening the emails when you make commits, which has mainly been on the race condition PR recently. |
|
I did honestly kind of drop this a bit since I didn't assign it to myself, it wasn't showing up in the GitHub search results I try to use to track everything happening. |
|
This feature is still not supported? Doesn't work for me :( |
Properly handles byte-range requests with multiple non-overlapping ranges by responding with a multipart/byterange response. For details on the specification for handling this type of request see RFC 7233
For example, a request looking like this:
Would generate a response like this: