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

Implement `slice(&self, range: impl RangeBounds<usize>)` for `HeaderValue`

Abierto
  • ¿Algo no está bien?
#810 3 comentarios 0 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
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust
Área
api

Línea de trabajo

Comienza revisando las APIs existentes de almacenamiento compartido de HeaderValue y, después, inspecciona Bytes::slice y la alternativa discutida en issue #459. Determina qué interfaz quieren los maintainers y considera el comportamiento de los rangos y las implicaciones de ownership; el trabajo estará terminado cuando la API elegida esté implementada con una cobertura y documentación adecuadas.

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

Descripción

NB. I initially opened this issue suggesting implementing std::ops::Index instead of a slice method. That original proposal wouldn't work because the trait would always returns a &HeaderValue (a &<Self as Index>::Output) and I'm proposing a method that returns an owned HeaderValue.

My motivation for this is to simplify handling list-based header values in a way that avoids copying the HeaderValue's data. Consider If-None-Match, which may contain multiple comma-separated entity-tags, or Cookies which may contain multiple semicolon-separated cookie-pairs. In both cases, it's necessary to operate on individual values within the list, and sub-slicing is a natural choice;

let inm = HeaderValue::from_static(
    r#"If-None-Match: W/"67ab43", "54ed21", "7892dd""#,
);
assert_eq!(&inm.as_bytes()[15 .. 25], br#"W/"67ab43""#);
assert_eq!(&inm.as_bytes()[27 .. 35], br#""54ed21""#);
assert_eq!(&inm.as_bytes()[37 .. 45], br#""7892dd""#);

The above works well if 1. you can limit operations to &[u8]s and 2. you can manage the lifetime of the borrowed-from HeaderValue. Both of those limitations seem unnecessary given HeaderValue's Arc-like memory characteristic, so it's more natural to my mind to allow something like the below,

let inm = HeaderValue::from_static(
    r#"If-None-Match: W/"67ab43", "54ed21", "7892dd""#,
);
assert_eq!(inm.slice(15 .. 25), HeaderValue::from_static(r#"W/"67ab43""#));
assert_eq!(inm.slice(27 .. 35), HeaderValue::from_static(r#""54ed21""#));
assert_eq!(inm.slice(37 .. 45), HeaderValue::from_static(r#""7892dd""#));

This would be a relatively simple change to make using Bytes::slice to do the heavy lifting.

I haven't put together a PR for the above yet because I see two open questions that I feel a maintainer may want to weigh in on.

First is whether or not this should be done at all. Returning a HeaderValue from a method named slice (rather than a &HeaderValue) may be surprising in the broader context. It would also implicitly codify the use of Bytes — or some other Arc-like memory management system — in the type's interface. I don't see either of these as blockers, given from_maybe_shared is precedent for both, and HeaderValue has been backed by Bytes for years now.

Second, and maybe more interesting, is whether this kind of interface would be better or worse than directly exposing the underlying Bytes object as per #459. Rather than offering a HeaderValue::slice method, consumers could directly call Bytes::slice, e.g.

let inm = HeaderValue::from_static(
    r#"If-None-Match: W/"67ab43", "54ed21", "7892dd""#,
);
let b_inm: Bytes = inm.as_shared();
assert_eq!(b_inm.slice(15 .. 25), Bytes::from_static(r#"W/"67ab43""#));
assert_eq!(b_inm.slice(27 .. 35), Bytes::from_static(r#""54ed21""#));
assert_eq!(b_inm.slice(37 .. 45), Bytes::from_static(r#""7892dd""#));

I'd be happy to put up a PR for either change.

Lenguaje dominante
Rust
Estrellas
1.4k
Forks
380
Merge medio
2 d 5 h
PR fusionados (30 d)
4

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/http

Todos los issues de hyperium/http

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.