[AlexeyMatskevich]

A client that resumes a download with Range and If-Range after the file was replaced gets 206 with a slice of the new file and appends it to the old bytes. With this PR, Range is applied only when If-Range still matches the file; otherwise the client gets the whole file.

What changes

• With a stale entity-tag or the weak form W/"…" of the current tag in If-Range, the response is 200 with no Content-Range (test: test_named_file_if_range_mismatch).
• The same for a date later or earlier than Last-Modified (tests: test_named_file_if_range_mismatch, test_named_file_if_range_earlier_date).
• The same for a value that is neither an entity-tag nor a date, or is not valid UTF-8 (tests: test_named_file_if_range_mismatch, test_named_file_if_range_not_utf8).
• The same for a tag when use_etag(false) is set, and for a date when use_last_modified(false) is set (test: test_named_file_if_range_mismatch).
• An If-Range equal to the current strong ETag or to Last-Modified keeps the 206 (test: test_named_file_if_range_match).
• Through Files, a non-matching If-Range returns the whole file with 200 for a satisfiable and for an unsatisfiable Range (test: test_files_if_range).

Reference

actix-files fixed the same in actix/actix-web#4334.

This PR touches the same lines as "NamedFile: no panic on pre-epoch modification times or on an empty or degenerate Range" (ntex-files/src/lib.rs) and "NamedFile: evaluate preconditions before Range" (ntex-files/src/named.rs); the one merged later needs a rebase.

[fafhrd91]

thanks