Summary

FileResponse does not follow the specification for range requests. The problems are:

1. Omitting bytes in the value of the Content-Range header when a range request is not satisfiable.
2. When multiple parts are transferred, the value of the Content-Type header should be multipart/byteranges; boundary=<BOUNDARY> and Content-Range should be unset. FileResponse instead sets the Content-Range header to multipart/byteranges and sends the original Content-Type.
3. When multiple parts are transferred, all header lines should be separated by CRLFs, not LFs. A final CRLF after the last boundary is allowed, but not required. It is seen as the start of an optional epilogue.

These 3 issues are addressed by the first 3 commits. The last commit lets FileResponse make a copy of the headers before modifying them for a range response. This means that it is possible to use the same FileResponse instance multiple times. Not being able to use a FileResponse multiple times was the original reason I started looking into this, but it is not documented either way and it isn't technically a bug fix because of that, I think.

Open questions:

• Should FileResponse's constructor strip out a Content-Range header if it is passed in headers?

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.