Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Range header issues

Open
#197 2 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
networking

Research direction

Start with the Range header implementation and its Range::bytes and satisfiable_ranges entry points. Review the proposed ByteRangeSpec representation, iterator construction, collection-backed storage, and unknown-resource-size behavior; done means all four listed issues are addressed consistently.

Written by the indexing model from the issue text.

Description

The Range header is one of the least useful header types in this library. Most of these problems stem from the fact that it contains only a string HeaderValue, instead of a parsed representation of the Range.

  1. The internal representation of range endpoints passed to bytes and returned from satisfiable_ranges is Bound<u64>. But this is a very poor fit, because it suggests in the return type that Bound::Excluded would be a valid value to use in a Range header, when it is actually never possible for it to appear.

    headers should re-introduce the ByteRangeSpec enum to encode the three valid cases for the Range header.

  2. Range::bytes allows construction from a single impl RangeBounds<u64>. Range should be extended to allow construction from impl Iterator<ByteRangeSpec>.

  3. The internal representation of a Range is a string cloned from the HeaderValue passed to decode. It should instead be a collection of ByteRanges, perhaps a SmallVec<[ByteRangeSpec; 1]> since the expected case is that there will only be one range (multipart ranges are generally uncommon).

    If you are constructing or parsing this header, it is expected that you are going to access the fields, so the extra memory overhead of doing so is explicitly necessary. And the type already clones the string header value! Doing the SmallVec optimization would reduce the number of allocations by 1 for the typical case.

  4. satisfiable_ranges assumes the caller will know the size of the resource being fetched. It may not, in which case passing u64::MAX will return nonsense results when a suffix range is parsed.

Dominant language
Rust
Stars
200
Forks
107
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hyperium/headers

All issues in hyperium/headers

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.