search

dhensby / node-http-message-signatures

A node package for signing HTTP messages as per the http-message-signing draft specification
ISC License
13 stars 8 forks source link

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

Closed AlexanderTar closed 6 months ago

AlexanderTar commented 6 months ago

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 commented 6 months ago

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

dhensby commented 6 months ago

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

AlexanderTar commented 6 months ago

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

AlexanderTar commented 6 months ago

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 commented 6 months ago

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

github-actions[bot] commented 6 months ago

:tada: This PR is included in version 1.0.3 :tada:

The release is available on:

Your semantic-release bot :package::rocket: