fix: use undecoded @path, @query and @query-param according to the spec

[AlexanderTar]

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-19#name-path
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-19#name-query

[dhensby]

Good catch, thanks. Can we add test coverage for this?

[dhensby]

Also, I think this is a fix, not a feat. Would you mind amending the commit message please?

[dhensby]

@AlexanderTar alternatively, if you allow maintainers to make pushes to your PR branch, I can make the amendments to the PR

[AlexanderTar]

Hi @dhensby - Thanks for reviewing

I have added some test cases from the spec and also made sure it is correctly implemented for @query-param

Feel free to merge if you're happy with this

[dhensby]

Having to re-encode the query parameters is leading to inconsistencies and edge-case issues, really we need a way to get our hands on the raw value of the query string parameter and, I'm afraid, that looks like it'll mean manual parsing of the url.search prop.

[AlexanderTar]

Having to re-encode the query parameters is leading to inconsistencies and edge-case issues, really we need a way to get our hands on the raw value of the query string parameter and, I'm afraid, that looks like it'll mean manual parsing of the url.search prop.

According to the spec, this is the process for deriving @query-param component:

The value of the name parameter and the component value of a single named parameter are calculated by the following process:

1. Parse the nameString or valueString of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of [HTMLURL], which is the value after percent-encoded octets are decoded.
2. Encode the nameString or valueString using the "percent-encode after encoding" process defined by the "application/x-www-form-urlencoded serializing" section of [HTMLURL], which results in an [ASCII] string.
3. Output the ASCII string

My research showed that searchParams contains a map of URI decoded keys and values, so if name was provided with escaped characters, we have to decode it first before looking up. Similarly, once we found a respective value, it has to be encoded. I would imagine all edge cases should be covered by URL parsing code and as long as they are, we're safe to do encode-decode exercises

[dhensby]

Great - thanks for the clarification and the work put into these PRs! 🎉

[github-actions]

🎉 This PR is included in version 1.0.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀