Wait without a deadline guarantee
03wait expresses a preferred processing interval in seconds after server receipt. respond-async asks for asynchronous handling: reply before the work finishes. Its completion protocol is not defined here.
If the server spends ten seconds before responding and the return path takes two more, the client sees fourteen seconds in this example. This is not an end-to-end deadline; a server may ignore wait and take longer.
Source for this drawing: RFC 7240 · Read RFC section 4.3 ↗
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.
wait uses a non-negative decimal number of seconds; verified erratum 4316 corrects its reference to delay-seconds.
- wait uses a non-negative decimal number of seconds; verified erratum 4316 corrects its reference to delay-seconds.
- Servers or proxies can choose asynchronous processing, for example returning 202 Accepted. Both preferences may be ignored.
- Network and intermediary time adds to server processing time. A client may abandon a slow request; this does not specify server-side cancellation.
Examples show one chosen server policy. Preferences are optional; consult the linked requirements, errata and RFC 8144 WebDAV update.
Read the RFC section ↗