hyperium / hyperium/http

Implement common trait(s) to expose common traits of HTTP message (header) types

Open
#592 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.4k
Forks
378
Avg merge
1d 21h
Merged PRs (30d)
5

Description

All HTTP messages in the http crate contain a bunch of shared data: the version, the headers and the extensions. Both the Request and the Response also allow callers to separate the headers part of a message from the body, resulting in two Parts types that both carry all three of these fields, so there are 4 types in total that share the same underlying data. It would be nice if there was a way to abstract over this data.

For my purposes, I mostly care about the HeaderMap<HeaderValue> -- my direct use case is that I have a function that makes it easier to extract the header's value as a &str and would like to apply this easily to both a request::Parts (which our framework uses internally to carry around request state) and a Response -- but it might make sense to take care of all three in one interface.

We could just have four impl AsRef<HeaderMap<HeaderValue>> for all four of these types as a minimal solution, or we could implement a custom trait, maybe like this:

trait HttpMessage {
     fn version(&self) -> Version;
     fn headers(&self) -> &HeaderMap<HeaderValue>;
     fn extensions(&self) -> &Extensions;
}

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source files, tests, or entry points are named. Start by comparing the shared version, headers, and extensions data on Request, Response, request::Parts, and response::Parts. Done means agreeing on and implementing a common interface, or the proposed AsRef implementations, with coverage for the stated request-parts and response use cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.