Adding `SecWebsocketProtocol`/`SecWebsocketExtensions`
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- rust
- Ambito
- backend-api-design
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
(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.
- Lingua principale
- Rust
- Stelle
- 200
- Fork
- 107
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di hyperium/headers
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 78/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Link supportAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
Tutte le issue di hyperium/headers
Issue simili
-
area:casework bug criticality:p3 triage:needs-implementation
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
registrystack/registry-stack#1623 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
DioxusLabs/anyrender#98 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
leptos-rs/leptos#4885 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
longbridge/gpui-kit#3276 ·
I maintainer di solito rispondono entro 1 giorno