Choose the response body
04return=representation asks for current resource data; return=minimal asks for a small successful response. Neither dictates one universal status code.
A client sends return=minimal, return=representation. Section 4.2 allows treating this as neither specified. The picture chooses that policy; this is not a mandatory rejection or a universal override of first-occurrence processing.
Source for this drawing: RFC 7240 · Read RFC section 4.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.
A returned representation can avoid a follow-up GET. Content-Location can identify it when it represents a different resource from the request target.
- A returned representation can avoid a follow-up GET. Content-Location can identify it when it represents a different resource from the request target.
- Minimal is decided by the server: typically 204, but other appropriate responses are allowed, including a zero-length 200 or the published 201 example.
- The return choices are mutually exclusive; a request containing both can be treated as neither specified. RFC 8144 adds WebDAV-specific rules and extends representation responses to relevant 412 failures.
Examples show one chosen server policy. Preferences are optional; consult the linked requirements, errata and RFC 8144 WebDAV update.
Read the RFC section ↗