Adding `SecWebsocketProtocol`/`SecWebsocketExtensions`
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 prior art in issue #88 and the existing Header abstractions for how request and response values are represented. The issue names no files or tests; done would require an agreed design for constructing and validating Sec-Websocket-Protocol and Sec-Websocket-Extensions across both message directions.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
(prior art #88)
So, these headers are sorta weird in that they have different forms depending on whether they're in a request or a response. For Sec-Websocket-Protocol specifically, this is drastically different; Sec-Websocket-Protocol in a request is a comma-separated list of values, but Sec-Websocket-Protocol in a response is one single value picked out from that list. So, that makes it tricky to add as a Header, since there aren't any existing headers that have multiple forms like that. The way I did it in writing some websocket handshake code was to just have 2 separate types, RequestSecWebsocketProtocol and ResponseSecWebsocketProtocol, which works, but is verbose and kinda clunky. I was wondering, for theoretically eventually adding these to headers, if anyone had any ideas for better ways to do this? Or if maybe just having one SecWebsocketProtocol type is good enough, maybe with strict constructors that are explicit about constructing a list vs a handshake agreement.
- 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
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
NuSkooler/enigma-bbs#907 ·
Los mantenedores suelen responder en 1 día
-
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