Check content type and raw bytes
04The ct query parameter describes the expected media type. The application must also define which bytes are hashed.
Separate case: a client is not sensitive to content type. This particular conditional SHOULD does not trigger; other integrity and application checks still apply.
Source for this drawing: RFC 6920 · Read RFC section 3.1 ↗
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.
Implementations MUST support parsing ct=. For non-ASCII query content, UTF-8 octets MUST be percent-encoded (§3).
- Implementations MUST support parsing ct=. For non-ASCII query content, UTF-8 octets MUST be percent-encoded (§3).
- The hash is calculated after MIME Content-Transfer-Encoding is removed. Applications define the input rules for other content types; public keys SHOULD use SubjectPublicKeyInfo (§2).
- An implementation SHOULD support integrity validation for application/octet-stream without explicit transfer encoding. When a type-sensitive client has ct and the retrieval protocol supplies a type, a mismatch SHOULD be handled as a potential security error.
Also RFC6920 §§2–3.1,10. The helper consumes an already-decided media-type comparison, not a complete MIME parser. Worked values are public RFC examples or fictional teaching data. Naming, locating, and checking integrity are distinct operations.
Read the RFC section ↗