Parse parameters without splitting inside quotes
02A disposition token is followed by semicolon-separated parameters. A quoted string can contain characters that would otherwise separate syntax.
filename=a.txt and FILENAME=b.txt repeat the same case-insensitive parameter name. This sender path stops before emitting the invalid field, satisfying MUST NOT.
Source for this drawing: RFC 6266 · Read RFC section 4.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.
Parameter boundaries follow the grammar, not every visible semicolon.
- The grammar is disposition-type followed by zero or more semicolon-separated name=value parameters. A filename value can be a permitted token or quoted string; spaces require quoting.
- Disposition types and filename/filename* parameter names are matched case-insensitively. Optional whitespace can appear as allowed by the grammar.
- Multiple instances of the same parameter name make the field invalid. Senders MUST NOT generate invalid fields; filename and filename* are distinct names and can appear together.
The quoted semicolon example is fictional conforming syntax. The duplicate-name scene is a sender generation gate, separate from recipient error recovery in chapter5. A simple split on semicolons breaks quoted values. This is a grammar lesson, not a complete HTTP parser implementation.
Read the RFC section ↗