Handle recoverable errors
05handling expresses strict or lenient processing preferences when a request has an error the server could recover from. The server still decides what is safe and processable.
A request containing handling=strict and handling=lenient can be treated as neither specified. This example chooses the server default rather than inventing mandatory precedence or a rejection status.
Source for this drawing: RFC 7240 · Read RFC section 4.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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
handling=strict asks to reject a recoverable problem with an appropriate 4xx response; handling=lenient asks to attempt processing.
- handling=strict asks to reject a recoverable problem with an appropriate 4xx response; handling=lenient asks to attempt processing.
- Lenient does not make every invalid request processable, waive authorization or guarantee success.
- The choices are mutually exclusive; a request containing both can be treated as neither specified. Use handling=lenient, not the misleading bare Lenient token in §2.1 example 2.
Examples show one chosen server policy. Preferences are optional; consult the linked requirements, errata and RFC 8144 WebDAV update.
Read the RFC section ↗