Remove `range-parser` dependency

[kotx]

R2 API can process range requests now, it seems. We can remove the range-parser dependency and directly pass the header instead.

[Erisa]

It looks like the functionality to pass request headers to R2GetOptions is not documented outside of changelogs... nor does it actually work.

✘ [ERROR] Uncaught (in promise) Error: get: We encountered an internal error. Please try again. (10001)

As far as I can tell this bug is acknowledged but has existed for a while now without a fix. So this issue would be blocked waiting for that being fixed in future.

[Frederik-Baetens]

This should be fixed now. Let me know if you encounter any more issues surrounding this functionality.

[mon]

I started implementing this feature, they also support headers in onlyIf now so I removed them too.

Unfortunately the R2 API is fairly simplistic so there'd be some changes to responses:

• multiple ranges are not supported, and R2 simply returns the entire file (can't easily return "Range not satisfiable")
• invalid ranges simply return the entire file (e.g. the backwards range 500-5 has no error)
• suffix ranges are converted into "normal" ranges (e.g. file len 500, suffix 10, R2 returns R2Range{ offset: 490, length: 10}, so can't reply to the user's request directly
• even if no range header is present, R2 returns information in the range member of the file response (need to check the header ourselves)
• If-Range is not supported

If there is a cache HIT, then ranges work fully, which makes sense as the cache is designed for such usecases.

I think it's probably best to keep the existing behaviour. I don't think R2 can actually support ranges properly yet.

[kotx]

Thank you for investigating! Definitely seems like keeping the existing behaviour is better for now.
You're great for making 0x40-web btw!

[mon]

Hah, this is actually my project of moving 0x40 hues hosting to cloudflare, as I'm tired of maintaining my VPS. Directory listing is essential for the respacks folder!