Adding `SecWebsocketProtocol`/`SecWebsocketExtensions`
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- rust
- Domain
- backend-api-design
Research direction
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.
Written by the indexing model from the issue text.
Description
(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.
- Dominant language
- Rust
- Stars
- 200
- Forks
- 107
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hyperium/headers
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Link support Open
Difficulty 4/5 3-5 days Newbie friendliness 38/100
All issues in hyperium/headers
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
issue
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
web-infra-dev/rspack#15847 ·