Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Range header issues

Abierto
  • ¿Algo no está bien?
#197 2 comentarios 3 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust
Área
networking

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
200
Forks
108
Merge medio
3 d 2 h
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hyperium/headers

Todos los issues de hyperium/headers

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.