Add OAUTH_SIGNATURE EncodeSet

[alicemaz]

This character set is defined in rfc5849
https://tools.ietf.org/html/rfc5849#section-3.6
and is used to encode the signature base string and
and the "Authorization" header field

relevant bit of the oauth 1.0 rfc is:

• (ALPHA, DIGIT, "-", ".", "_", "~") MUST NOT be encoded.
• All other characters MUST be encoded.

tested with all ascii values 32-126 in both the signature and the header

[untitaker]

Since this part of the OAuth 1.0 RFC is just refering to unreserved in the URI RFC, I think a name should be chosen that isn't specific to OAuth.

I'm currently a bit confused about the naming scheme that is used for encoding sets, but it seems UNRESERVED_ENCODING_SET should be fine (I think?)

[alicemaz]

updated. agree it is a better name. I'm not sure what the comment should be changed to, if anything, to fit with the UNRESERVED name while keeping the "is used for" phrasing.

incidentally I noticed HTTP_VALUE_ENCODE_SET is not listed in the docs (https://servo.github.io/rust-url/url/percent_encoding/index.html), though it does exist in the copy of the file in the repo (https://github.com/servo/doc.servo.org/blob/gh-pages/url/percent_encoding/index.html#L89), but I don't know whether this is in error or where it would make sense to report this.

[untitaker]

Not sure either. ISTM that unreserved is often used in contexts where a proper URL parsing library (like this one) would do a better job at interpreting the URL correctly.

• The only usecase I really have is to normalize URLs using decode(url, UNRESERVED) (as specified in the RFC), but in Rust, rust-url already takes care of that.
• The other thing I've just learned about is that it's used in OAuth 1.0

So perhaps:

This encode set is used for URI normalization. It can also be used to implement other RFCs which rely on the definition of unreserved.

[untitaker]

where a proper URL parsing library (like this one) would do a better job at interpreting the URL correctly.

Ironically rust-url doesn't do percent-encoding normalization, so I've filed #149

[alicemaz]

thank you, updated.

[SimonSapin]

Rather than add this (and later another set for another use case, and another…) I’d like to do something like #151 so you could define this in your own crate. What do you think?

[untitaker]

@SimonSapin This particular set might actually be needed depending on your response to #149

[SimonSapin]

@untitaker I don’t understand how that particular set is relevant to #149, but that should probably be discussed there since this PR is originally about supporting OAuth.

[alicemaz]

@SimonSapin if I understand correctly, this would allow me to call the define_encode_set! macro once to create the ruleset in my program, then pass the result to the encoder as needed? that would fix my use case. specifically, all I need is to be able to do this exact encoding to arbitrary strings so when I hash them after it comes out right.

I don't know enough on the topic to have an opinion on whether this particular set ought to be in the lib proper for normalization in-browser and leave it to your judgement.

[SimonSapin]

if I understand correctly, this would allow me to call the define_encode_set! macro once to create the ruleset in my program, then pass the result to the encoder as needed?

Yes, exactly.

whether this particular set ought to be in the lib

My opinion of the scope of rust-url is "things defined in https://url.spec.whatwg.org/"

[bors-servo]

☔ The latest upstream changes (presumably #176) made this pull request unmergeable. Please resolve the merge conflicts.

[SimonSapin]

1.0.0 will be published tomorrow. It has a mechanism for defining your own encode set:
https://servo.github.io/rust-url/url/macro.define_encode_set!.html