Identify who implements the block
02A blocked-by link identifies the entity implementing a block, while the body can explain who demanded it.
The body names the fictional requesting authority, rule and scope. That authority is not the blocked-by link target.
Source for this drawing: RFC 7725 · Read RFC section 4 ↗
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
- Link relation
- The rel parameter describes how a linked URI relates to the response context.
- Implementer
- The entity actually blocking access, which can differ from the party demanding the block.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Keep the implementer separate from the authority demanding action.
- An entity that blocks access and returns 451 SHOULD include a Link header field with a URI reference identifying itself. The URI is an identifier/reference, not an instruction for the client to redirect there.
- When a Link header is used for that purpose, its rel parameter MUST have the value blocked-by. The SHOULD to include the header and the conditional MUST for its relation are different requirements.
- The link identifies the entity actually implementing the blockage, not another entity mandating it. Administrative and policy details belong in the human-readable response body.
Fictional example: Link: <https://filter.example/notice>; rel="blocked-by". The filter implements the block. The body separately names Example Authority, Fictional Rule A, and the affected Example Region audience and /report resources. These are invented policy details, not legal advice, authentication proof or a mandatory notice template.
Read the RFC section ↗