Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Range header issues

Aperta
#197 2 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
200
Fork
107
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyperium/headers

Tutte le issue di hyperium/headers

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.