Skip to content

Add unsatisfied_requirements() for unclaimed req- params - #14

Closed
caarloshenriq wants to merge 1 commit into
payjoin:masterfrom
caarloshenriq:feat/unsatisfied-requirements
Closed

caarloshenriq wants to merge 1 commit into
payjoin:masterfrom
caarloshenriq:feat/unsatisfied-requirements

Conversation

@caarloshenriq

Copy link
Copy Markdown

Part of #12

Add a new field and public accessor to Uri. This reports the req- parameter keys that were present in a URI but not claimed by extras. Always empty for a Uri built through FromStr or TryFrom<&str>, since those already fail immediately on the first unclaimed req- parameter, per BIP21.

Add two new opt-in entry points, Uri::parse_permissive and Uri::try_parse_permissive, that share the same parsing logic via a new deserialize_raw_impl(string, permissive) but do not fail on an unclaimed req- parameter. Instead they record its key and keep parsing, letting a caller decide afterward whether to accept the URI anyway.

Disclosure: co-authored by Claude

Add a new field and public accessor to `Uri`. This reports the
req- parameter keys that were present in a URI but not claimed by
`extras`. Always empty for a `Uri` built through `FromStr` or
`TryFrom<&str>`, since those already fail immediately on the first
unclaimed req- parameter, per BIP21.

Add two new opt-in entry points, `Uri::parse_permissive` and
`Uri::try_parse_permissive`, that share the same parsing logic via
a new `deserialize_raw_impl(string, permissive)` but do not fail on
an unclaimed req- parameter. Instead they record its key and keep
parsing, letting a caller decide afterward whether to accept the
URI anyway.
@DanGould

DanGould commented Oct 2, 2026

Copy link
Copy Markdown
Member

When do we want this to be permissive? don't we always want to error if there's an unknown req-?

@caarloshenriq

Copy link
Copy Markdown
Author

When do we want this to be permissive? don't we always want to error if there's an unknown req-?

Right, the permissive/strict split doesn't belong in the parser, it can't know which req- keys a client implements. #12 moves this to unsatisfied_requirements(understood) at the call site, so closing this in favor of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants