Bound size and check interpretation policy
05Short inline data is useful, but valid decoding neither grants permission to interpret a type nor guarantees an application can handle its size.
A separate short data:text/html,Hi URL is within the budget but its marked text/html type is disallowed. Stop before interpretation, even though Hi is easy to decode.
Source for this drawing: RFC 2397 · Read RFC section 6 ↗
New to this? Start hereA quick picture + helpful background
A request starts a conversation.
A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.
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.
Decodeable is not authorized or harmless.
- RFC2397 describes short values and warns about applications with length limits or fixed buffers. Its HTML2.0 SGML limits are historical examples, not universal limits for modern browsers.
- An application should not interpret a data URL whose marked media type is disallowed by its configuration. The security considerations of the media type still apply.
- Inline active content can evade policies that only screen external retrieval through a firewall proxy. Applications need suitable controls for carried content as well; encoding does not remove its risks.
The worked policy allows only text/plain and chooses a maximum URL length of 32 characters. Those values and the rejection messages are local example policy, not RFC mandates. The guide is not a browser origin, navigation, CSP, MIME sniffing or sandbox specification. No actual HTML/script/image interpretation, external request or trust decision is performed. Size checks precede decoding in the teaching gate.
Read the RFC section ↗