Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Usability issues with `Authorization` parsing

Đang mở
  • Có gì không ổn?
#229 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
rust
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
200
Fork
108
Merge trung bình
3 ngày 2 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của hyperium/headers

Tất cả issue của hyperium/headers

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.