Add support for SVCB and HTTPS #112
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial (not very optimized) implementation of RFC9460. The SVCB RRTYPE is different from all other RRTYPEs in that it requires RDATA to be sorted (unless secondary, in which case we serve what we have). To avoid additional allocations, I've implemented a strict mode that moves existing RDATA out of the way, updates the maximum size, parses the RDATA for the parameter being parsed and move data that was already there to the right position. It's not "efficient", because we need to iterate the data in linear fashion, but since we're parsing we're already doing that. IMHO it's better than separate allocations and using qsort afterwards, although in NSD, that really makes more sense. Ideally, operators make sure the keys are in wire-format order, in which case it's way more efficient that doing separate allocations.
This does introduce the concept of
rdata_t, sort-of an RDATA view. It's best if that concept is used by all other parse functions too. As we'll need to cleanup the API a little bit before the initial release, I'll add that later.