Closed pjenvey closed 6 years ago
How do you feel about relaxing this and allowing all ASCII, not just Base64url?
Base64url might make the client's life harder in some cases: the update service, for example, uses an ETag
, which is an opaque, possibly quoted string...it would be nice if clients didn't have to parse or hash that, or store a separate value for Megaphone.
The urlsafe b64's just for the ids in the URL itself, the payload (version) is ascii.
But even an ETag based on some urlsafe b64 value shouldn't be an issue (it's a subset of ascii)?
What's confusing here though is we're using 'url safe base64' as a definition of allowed characters. I'm not intending for update services to base64 encode their ids, e.g. a broadcasterId will be "remote-settings", not "cmVtb3RlLXNldHRpbmdz".
(And technically this is all unpadded url safe base64.. so our terminology is bad)
Sorry, late to the party, but that makes perfect sense, @pjenvey; thanks! I didn't read your PR carefully enough. The ETag
is ASCII-only, but it does have embedded quotes, and so I was wondering if we could use it as the version directly, instead of double-encoding. It looks like the answer is yes. 😄
and bump to latest rocket/rust nightly
Closes #24