empower headers users in defining their own headers
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- rust
- Área
- backend-api-design
Línea de trabajo
Start by reviewing the crate's public typed-header API and the utilities named in the issue, including CSV parsing and HttpDate. Examine ContentType's construction limits and consider how externally defined headers or an unstable extension surface would fit. Done would require a decided scope and API design, followed by implementation and tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
This crate comes with a lot of utilities which aren't available in public API space. This leads to people having to define their own utilities for very similar headers. In case this crate would be ok in adding a lot more (semi) std http headers that would be less of an issue, but AFAIK it is intended to keep this crate limited to the more popular ones and certainly not X- like headers, even though plenty of them are pretty standard.
With utilities I mean CSV parsing, HttpDate, etc...
I'm fine with this being behind an unstable feature or w/e, but right now you pretty much need to copy them out which is a lot harder to keep in sync then just having your code break with an update.
Similar, a lot headers that are supported here have also severe limitations in how they can be used, making it now always easy or even possible to use the typed headers due to these limitations. E.g. ContentType only has support for a couple of content-types to construct them with, just to give an example.
All in all this crate (headers) is fantastic, but I feel it is currently a lot more limited in how it can be used as well as externally extended.
- 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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de hyperium/headers
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
Range::bytes and ContentRange::bytes do unchecked u64 arithmetic on boundsPosiblemente ocupada @youdie006 la tomó hace 57 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
-
From<SystemTime> for HttpDate panics on times before 1970 or after year 9999Posiblemente ocupada @SAY-5 la tomó hace 76 días. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Link supportAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
Todos los issues de hyperium/headers
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
EasyTier/EasyTier#2672 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
XmlFragment children, successors and siblings stop at the first child that is not an XML typeAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
bug good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
repowise-dev/repowise#3374 ·
Los mantenedores suelen responder en 1 día
-
awaiting-response bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
wildcard/caro#1562 · 1 comentario ·
Los mantenedores suelen responder en 3 días