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

Usability issues with `Authorization` parsing

Abierto
  • ¿Algo no está bien?
#229 1 comentario 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
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
api, backend-api-design

Línea de trabajo

Start with the Header::decode entry point used by headers::Authorization::headers::authorization::Bearer in the three supplied test cases. Define behavior that distinguishes a missing or wrong scheme from a malformed or potentially suitable Authorization header, including the requested support for multiple schemes; done means callers can reliably produce the expected 401 or 400 outcomes.

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

Descripción

Version

headers 0.4.1

Platform

Darwin [snip] 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:06 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6030 arm64

Summary

It's impossible for a caller to differentiate between the cases needed.

Broadly speaking, I think there are 3 different returns from parsing this header:

  1. The Authorization header is present, well-formed. (And maybe, of a type we support.) We probably want an Ok(…) here, and the caller will translate this to either 200 or 401, depending on the validity of the credentials supplied.
  2. The Authorization header is missing altogether. The caller will likely want to return a 401. (Or otherwise treat the request as unauthenticated.)
  3. The Authorization header is present and malformed. The caller will want to return a 400.

Distinguishing between these cases accurately with the library is tough. Err(Invalid) is returned if the header isn't parsable, so we might think that should be translated to 400. But it's also returned in the absence of the header, or if the header is present and well-formed, but we want Bearer but got Basic, or something similar. In that case, it should be a 401. But there is no means for the caller to distinguish these cases.

I've attached a test case; the assert! statements are not authoritative, since there's not really a good way to write the right asserts here.

Code Sample
#[cfg(test)]
mod tests {
    use headers::Header;

    #[test]
    fn test_no_headers() {
        let result = headers::Authorization::<headers::authorization::Bearer>::decode(&mut [].into_iter());
        println!("result = {:#?}", result);
        // This isn't an error per se — the request isn't malformed. We'll want to return a 401.
        assert!(result.is_err());
    }

    #[test]
    fn test_multiple() {
        let headers = [
            http::HeaderValue::from_static("Bearer 123"),
            http::HeaderValue::from_static("Basic dXNlcjpwYXNz"),
        ];
        let result = headers::Authorization::<headers::authorization::Bearer>::decode(
            &mut headers.iter(),
        );
        println!("result = {:#?}", result);
        // This should be an error: multiple `Authorization` headers are malformed, but this will
        // assert.
        assert!(result.is_err());
    }

    #[test]
    fn test_wrong() {
        let headers = [
            http::HeaderValue::from_static("Basic dXNlcjpwYXNz"),
        ];
        let result = headers::Authorization::<headers::authorization::Bearer>::decode(
            &mut headers.iter(),
        );
        println!("result = {:#?}", result);
        // This isn't an error per se — the request isn't malformed, but the expected header isn't
        // present. We'll want to return 401.
        assert!(result.is_err());
    }
}
Expected Behavior

A caller can accurately distinguish "wrong auth", "malformed message", and "potentially suitable auth".

Actual Behavior

There's only 1 error value, so that is impossible.

I wonder if -> Result<Option<Authorization>, _> would suffice, but I don't know if that's possible with the trait.

Additional Context

Obviously, the caller can do some pre-parsing … but what's the point of the library? 😉

I would also want a generic implementation of Authorization that can handle multiple/all types, in the case that one might accept Bearer or Basic. Yes, we can make two passes at parsing the header, but we'd repeat all the work of finding the scheme, which is a bit of a bummer.

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.