Build the token from allowed characters
02The grammar is a scheme name, a colon, and one or more pchar characters. pchar comes from URI syntax: letters, digits, selected punctuation and valid percent-encoded octets.
secret-token:caf%C3%A9%20%2F is the complete generated string. Bare %, empty token and raw / are invalid scheme syntax.
Source for this drawing: RFC 8959 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The token is nonempty: secret-token-URI = secret-token-scheme ":" token; token = 1*pchar. URI syntax is not an entropy or authorization check.
- The token is nonempty: secret-token-URI = secret-token-scheme ":" token; token = 1*pchar. URI syntax is not an entropy or authorization check.
- pchar permits unreserved characters, sub-delimiters, colon and @, plus % followed by two hexadecimal digits. A raw slash, question mark, hash, space or non-ASCII character is outside pchar.
- Disallowed characters MUST be encoded into UTF-8 and then percent-encoded. Apply encoding when issuing the token; do not rewrite a token that was already issued.
- This is a token identifier, not a web address to visit. A percent-encoded slash is token data, not a path separator.
RFC8959 §2 and RFC3986 §§2.1,2.2,2.3,3.3. Diagram proportions are schematic; café / is a fictional low-entropy teaching value, not a usable credential.
Read the RFC section ↗