Do not cache range requests

[ThatHackerDudeFromCyberspace]

File streaming, at least for videos is broken in the current version of Webrick

It seems that Chrome (and other browsers?) closes the initial Range request early, as such the server believes that the rest of the file is cached by the browser despite this not being the case.
As such, when the browser requests the rest of the file, the server responds with 304 - which causes streaming to fail

A simple fix for this is simply to not cache range requests

[jeremyevans]

Can you check what headers the browser is sending? It looks like the if-range header is handled incorrectly by webrick (should return 206 and not 304 if there has been no modification).

I don't think this patch is correct, since the server should return 304 in the cases where if-modified-since/if-none-match is provided and there is no modification, even for range requests. Behavior should only be changed for if-range, I think. We should probably move the if-range handling out of not_modified? and put it directly in the elsif req['range'] block, fixing it to return 206 (no modification) or 200 (if modified).

Additionally, the patch should only include updated tests.

[metade]

I had a go at fixing this here - #173

Note that most of this was done by AI, so I'm not very comfortable making this PR but let's see!