Extend handling of range headers in the sample
When testing the R2 with this worker sample, I ran into some applications (e.g. VLC) failing to read the data and failing immediately, due to corrupted network stream errors.
This was because they perform range requests which have optionally the offset or end missing, which the original sample doesn't handle correctly. This adds proper handling for those headers, which fixes those applications not working with this sample.
It also adds the "accept-ranges" header. Some apps seem to be confused when it's missing, while some ignore it, but change their behavior (how they send the range headers) when it's present.
I'm not sure if there are any unexpected side effects to these changes, but from my testing so far, it seems to work pretty well and I figure it might help other be less confused when their apps fail to work with the sample.
The latest runtime release should remove the need for doing range header parsing yourself, you can simply pass the request headers into the R2GetOptions and the returned object has a range option that'll contain the actual returned range, in the event that your requested range couldn't be satisfied.
https://community.cloudflare.com/t/2022-8-12-workers-runtime-release-notes/410873?u=kiannh
The Demo Worker could probably be cleaned up to utilise those two features, since they've landed since that Worker was added to the documentation.
Yeah I agree with @KianNH. The worker should just use the available methods instead of doing parsing by hand.