Apply a query and a client fragment
05A q-component can become the query of a returned locator. A fragment is interpreted for the retrieved representation, normally at the client.
Independent case: the returned locator already has ?lang=en. RFC 8141 leaves combination behavior unspecified and says resolvers SHOULD document their strategy. This guide stops automatic merging and asks for that policy.
Source for this drawing: RFC 8141 · Read RFC section 2.3.2 ↗
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.
Query parameters and fragments serve different consumers.
- For a URN resolved to a locator, copy q into the locator’s query. If that locator already has a query, RFC 8141 specifies no required combination behavior; resolvers SHOULD document their strategy.
- A fragment identifies a part or region according to the representation’s media type. For a single returned locator, f can usually be applied by the client as that locator’s fragment.
- q and f do not affect URN-equivalence. Their general interpretation is undefined here if the URN does not resolve to a locator; the chapter assumes a returned HTTP locator and meaningful application parameters.
Hypothetical fixture: urn:example:book-7?=view=short#part maps to https://books.example/read. The q keyword view and fragment part have only the chosen application’s meaning. Fragment contents are not sent in an HTTP request target. This is not a generic rule to merge existing queries or resolve every URN.
Read the RFC section ↗