[PR #255] [MERGED] Fix Range requests to correctly interpret last-byte-pos #462

New issue

Closed

opened 2026-03-03 12:30:08 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 12:30:08 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/fsouza/fake-gcs-server/pull/255
Author: @chowey
Created: 5/28/2020
Status: ✅ Merged
Merged: 5/28/2020
Merged by: @fsouza

Base: master ← Head: rangereader

📝 Commits (2)

c8734ea Fix Range requests to correctly interpret last-byte-pos
af12fd5 Update existing tests

📊 Changes

2 files changed (+54 additions, -4 deletions)

View changed files

📝 fakestorage/object.go (+4 -2)
📝 fakestorage/object_test.go (+50 -2)

📄 Description

I was having a problem with mocking NewRangeReader. My reads were giving me one-fewer bytes than I was expecting. I think I narrowed down why.

For Range request headers, per RFC 7233:

byte-range = first-byte-pos "-" last-byte-pos

In other words, the byte-range uses the last-byte-pos. This is subtly different than how Go slice indexing works per the Go language spec:

The indices low and high select which elements of operand a appear in the result. The result has indices starting at 0 and length equal to high - low.

Therefore, we should take the last-byte-pos from the Range header and increment it by one to get the high that is expected by Go.

I created a test that illustrates the point. When I use the GCS NewRangeReader function, which has a length parameter, the old code would return length-1 bytes.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/fsouza/fake-gcs-server/pull/255 **Author:** [@chowey](https://github.com/chowey) **Created:** 5/28/2020 **Status:** ✅ Merged **Merged:** 5/28/2020 **Merged by:** [@fsouza](https://github.com/fsouza) **Base:** `master` ← **Head:** `rangereader` --- ### 📝 Commits (2) - [`c8734ea`](https://github.com/fsouza/fake-gcs-server/commit/c8734eac00ae6595852634894212e78c50eeeea8) Fix Range requests to correctly interpret last-byte-pos - [`af12fd5`](https://github.com/fsouza/fake-gcs-server/commit/af12fd5ae1e54f5b6b0a3125fb87e1f4b2799297) Update existing tests ### 📊 Changes **2 files changed** (+54 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `fakestorage/object.go` (+4 -2) 📝 `fakestorage/object_test.go` (+50 -2) </details> ### 📄 Description I was having a problem with mocking `NewRangeReader`. My reads were giving me one-fewer bytes than I was expecting. I think I narrowed down why. For Range request headers, per [RFC 7233](https://tools.ietf.org/html/rfc7233#section-4.2): > `byte-range = first-byte-pos "-" last-byte-pos` In other words, the `byte-range` uses the `last-byte-pos`. This is subtly different than how Go slice indexing works [per the Go language spec](https://golang.org/ref/spec#Slice_expressions): > The *indices* `low` and `high` select which elements of operand `a` appear in the result. The result has indices starting at 0 and length equal to `high - low`. Therefore, we should take the `last-byte-pos` from the Range header and increment it by one to get the `high` that is expected by Go. I created a test that illustrates the point. When I use the GCS `NewRangeReader` function, which has a `length` parameter, the old code would return `length-1` bytes. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>