fix #716 (Add partial content with range)

[WebFreak001]

Mostly based on #716 (comment)

Changes to that comment: added -[X] format and sending partialContent status code. Also some cleaner code and checks against bad requests.

Not sure how to add an automatic test but I did manually test it locally using this very simple file server in chrome and firefox:

import vibe.http.server;
import vibe.http.fileserver;

shared static this()
{
	auto settings = new HTTPServerSettings;
	settings.port = 10716;
	listenHTTP(settings, serveStaticFiles("data"));
}

My aim was only fixing media streams (audio & video + seeking), but pausing downloads and resuming also works now.

[WebFreak001]

Using this on my websites now and everything seems to work as expected and users don't complain about video playback anymore. (Asked them explicitly for issues)

[s-ludwig]

The range can also have "/\d+" or "/*" as an additional suffix, and multiple ranges can be separated by comma. We should probably check that s.length == 2 and that range.canFind(','). Actually supporting this feature seems less important, though.

Edit: Misread the part with the slash suffix, that applies really only to the response.

[s-ludwig]

"" - not sure if that's just my browser, but that's supposed to be a backslash.

[WebFreak001]

I don't really know how to send the response back to the user when there is a comma in the request. Like imagine you request the first and last character, should the response be both characters combined together or should it be different?

[s-ludwig]

It needs to be sent using a multi-part response. But I'd just send a 400 Bad Request back instead, as I don't think that any typical client will ever request multiple ranges.

[s-ludwig]

...or rather 501 Not Implemented

[s-ludwig]

Instead of res.bodyWriter.write(new LimitedInputStream(fil, rangeEnd - rangeStart + 1));, write accepts a length parameter: res.bodyWriter.write(fil, rangeEnd - rangeStart + 1);. The writeRawBody optimization (enables the use of sendfile) could also be used for the range, but I'm afraid that this will uncover a bug in the current implementation (I think it doesn't check File.tell before calling sendfile).

The functionality itself looks good AFAICS.

[s-ludwig]

Okay, looks good to merge. Thanks for tackling this!

I'll look into adding a test after the merge.

[yazd]

You need to check length of s before you access s[1].
The client can send malformed headers.

[WebFreak001]

Uh well this PR is merged already and I recreated the repo so I can't edit this anymore, I will make a separate PR.