Validate Text Limits Across URI Percent-Encoding Layers

Use this procedure when Unicode text is placed in a URI path segment, query component, or form-encoded request and a contract limits one or more of these:

• semantic text units in the decoded value;
• UTF-8 bytes of the value before URI escaping;
• bytes of the encoded component;
• bytes of the complete request target.

These are different boundaries. Passing one limit does not prove that another limit passes.

Name every measured layer

Record each applicable rule before implementing validation:

1. The semantic unit: grapheme clusters, Unicode code points, or a contractually named code-unit scheme.
2. The text stage where semantic counting occurs, including any required normalization.
3. Whether a byte limit applies before percent encoding, after percent encoding, or to the complete request target.
4. The component grammar and encoder mode. A path segment, a query component, and an application/x-www-form-urlencoded field do not necessarily escape the same characters.
5. Whether the maximum is inclusive.
6. Whether delimiters such as question mark, ampersand, equals sign, slashes, and fixed parameter names are inside the measured boundary.

Do not call all of these measurements URL length. Give each one a precise name.

Validate an outbound value

1. Begin with the semantic value, not a pre-escaped string.
2. Apply only normalization required by the contract.
3. Count the specified semantic units and enforce the semantic limit.
4. Encode that same value as UTF-8 and enforce any pre-escape byte limit.
5. Pass the value through the production URI or form encoder exactly once.
6. Build the real component or complete request target, including every delimiter and fixed field covered by the contract.
7. Obtain the exact byte sequence handed to the transport and enforce the encoded boundary there.
8. Report failures by boundary so a semantic-limit error cannot be confused with an encoded-size error.

Do not predict encoded size by multiplying a character count. Unescaped characters may occupy one or more transmitted bytes, while each percent-encoded octet is represented by three ASCII bytes. Encoder policy also decides which eligible characters remain unescaped.

Validate an inbound value

1. Enforce any raw request-target byte ceiling at the raw boundary before allocating or decoding an unbounded value.
2. Parse with the production component grammar.
3. Reject malformed percent triplets and invalid UTF-8 according to the protocol policy. Do not silently replace invalid sequences when validation requires exact text.
4. Decode exactly once. Treat a decoded percent sign as data unless the contract explicitly defines another decoding layer.
5. Apply required normalization, then count the specified semantic units.
6. If the contract also limits decoded UTF-8 bytes, re-encode the validated decoded value as UTF-8 and count that representation separately.

A limit on raw encoded bytes is not a substitute for a limit on decoded semantic content, and the reverse is also true.

Account for encoder variants

Use the actual production encoder because these choices change size:

• A space may become plus in form encoding or percent two zero in ordinary percent encoding.
• A slash may remain a path delimiter, be data inside a segment, or be encoded.
• Reserved characters may be escaped differently depending on whether the encoder receives a whole URI or one component.
• Existing percent characters can expand again if already escaped input is accidentally encoded a second time.
• Parameter order, repeated keys, fixed names, separators, and fragments affect a whole-target limit even when each value fits alone.

Validate structured values before encoding and retain structure until final serialization. Concatenating pre-escaped fragments makes ownership of delimiters and escaping ambiguous.

Reasoned boundary examples

These examples are reasoned from UTF-8 and percent-encoding rules; they are not executed tests.

• ASCII A is one code point and one UTF-8 byte. When left unescaped, it is one request-target byte.
• Precomposed é is one code point and two UTF-8 bytes. If both UTF-8 octets are percent encoded, the encoded text is %C3%A9, which occupies six ASCII bytes.
• A scalar encoded as four UTF-8 bytes occupies twelve ASCII bytes when all four octets are percent encoded.
• A space occupies one UTF-8 byte, but its encoded representation may occupy one byte as plus in form encoding or three bytes as %20.
• Two values can have equal semantic counts and equal pre-escape UTF-8 sizes yet produce different encoded sizes when the encoder leaves different characters unescaped.

These examples do not determine the size of a complete request target. Add the exact names, delimiters, path, query marker, and other material included by the contract, then measure the result.

Focused verification

Create cases at the exact limit and immediately over it for every contracted boundary. Include:

• ASCII unreserved characters;
• two-byte, three-byte, and four-byte UTF-8 scalar values;
• precomposed and decomposed visible equivalents;
• spaces under the selected encoder mode;
• percent signs and characters reserved by the selected component grammar;
• a value that passes semantic count but fails the pre-escape byte limit;
• a value that passes the pre-escape byte limit but fails after percent encoding;
• individually valid components whose delimiters and fixed fields make the complete request target too large;
• malformed percent triplets, invalid UTF-8, and accidental double encoding for inbound validation.

For outbound integration tests, assert against the exact transmitted request-target bytes. For inbound tests, assert both the raw boundary decision and the decoded semantic decision. Keep these assertions separate so a change in encoder behavior reveals which contract moved.

Evidence status

This is a reasoned procedure derived from Unicode, UTF-8, and percent-encoding layer semantics. No executable tests, packet captures, production observations, external sources, or reviewer approvals support this skill. Concrete implementations must verify their runtime encoder, parser, normalization policy, and protocol contract.