Lazily parse TLS vector contents to eliminate intermedaite `Vec` construction
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- rust
- Domain
- networking, security
Research direction
Start by reading the TLS handshake vector parsing code that performs iter().try_map(T::decode).collect<Vec<_>>(), then review the proposed iterator support in #906. Identify which vectors can remain lazy without duplicate detection, and compare validation behavior with the current eager parsing. Done means practical cases avoid intermediate Vec construction while preserving the intended parsing behavior.
Written by the indexing model from the issue text.
Description
When we parse a TLS handshake message, we eagerly parse the contents of each TLS vector, constructing a Vec<_> containing the parsed and validated contents, using code equivalent to this:
let a = vector_contents.iter().try_map(T::decode).collect<Vec<_>>?;
My suggestion is that we avoid the collect step in as many cases as practical so that we instead operate on the iterators that lazily do the parsing/conversion as each entry is looked at. This should become practical to do if we implement #906.
This would divorce the order in which we validate the contents of the vectors from the order they appear in the structures.
This would also reduce the amount of validation we do, limiting it to the contents of the vectors we actually look at. IMO this is a good thing because it's good for performance, though it's different than what we do today. This works especially well if we avoid trying to detect duplicates in the vectors.
- Dominant language
- Rust
- Stars
- 7.7k
- Forks
- 947
- Avg merge
- 3d 11h
- Merged PRs (30d)
- 46
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
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 rustls/rustls
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 22/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 12/100
rustls/rustls#3409 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rustls/rustls#3373 · 3 comments ·
Maintainers usually reply within 1 day
Similar issues
-
ライブラリを追加Openpriority middle
Difficulty 1/5 Under an hour Newbie friendliness 62/100
KATO-Hiro/AtCoderClans#13015 ·
Maintainers usually reply within 1 day
-
needs-review
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
UCS-Care-Group/mailcraft#1429 ·
Maintainers usually reply within 1 day
-
priority: medium ready
Difficulty 1/5 Under an hour Newbie friendliness 88/100
TusanHomichi/PSIV#646 ·
Maintainers usually reply within 1 day
-
area:tui bug P1
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
agent-of-empires/agent-of-empires#5705 · 1 comment ·
Maintainers usually reply within 1 day
-
bug lab rust-mcp
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day