Implement common trait(s) to expose common traits of HTTP message (header) types
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
Piste de recherche
Aucun fichier source, test ou point d’entrée n’est nommé. Commencez par comparer les données partagées de version, headers et extensions dans Request, Response, request::Parts et response::Parts. Le travail sera considéré comme terminé lorsqu’une interface commune, ou les implémentations AsRef proposées, aura été convenue et implémentée, avec une couverture des cas d’utilisation indiqués pour request-parts et response.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
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;
}
- Langage dominant
- Rust
- Étoiles
- 1.4k
- Forks
- 385
- Merge moyen
- 1 j 5 h
- PR mergées (30 j)
- 2
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de hyperium/http
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 52/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 62/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 58/100
Toutes les issues de hyperium/http
Issues similaires
-
documentation P2
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
bug good first issue priority:high
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
Konfirm-xyz/konfirm-contracts#163 ·
Les mainteneurs répondent en général sous 1 jour
-
area:gc-repack-output bug factory:dogfood factory:triaged priority:p3 type:bug type:ux
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
gitbutlerapp/grit#1161 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour
-
feature performance
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
lance-format/lance#10137 ·
Les mainteneurs répondent en général sous 2 jours