Describe what caused a request
06An Origin request field describes the origin context that caused a request. It is not the destination URI, a username, or a standalone authorization decision.
A user agent generating two Origin fields violates MUST NOT. Stop that generation before sending; two field lines are not the RFC’s one-field space-separated list.
Source for this drawing: RFC 6454 · Read RFC section 7 ↗
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.
RFC 6454 permits the field but constrains how a user agent generates it.
- A user agent MAY include Origin in any HTTP request, but MUST NOT include more than one Origin field. The API determines what context caused the request.
- For a privacy-sensitive context, the user agent MUST send the value null. RFC 6454 leaves the definition of that context to applications.
- Each serialized origin MUST be ASCII. The RFC grammar permits a space-separated list, and the user agent MUST omit a consecutive duplicate; this is not a comma-separated list.
This chapter teaches the 2011 RFC, not a claim that current browser Fetch/CORS redirect handling sends this list. Rejected erratum 3249 proposed narrowing the grammar; it did not amend the RFC. Modern API behavior needs its own specification. A server must apply its own authorization and request protections; arbitrary clients can supply fields.
Read the RFC section ↗