WATCH: A Proposed HTTP Method for Event-Driven Subscriptions
draft-hunt-httpbis-watch-method-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dawson Hunt , Quill | ||
| Last updated | 2026-03-31 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hunt-httpbis-watch-method-00
httpbis D. Hunt
Internet-Draft Independent Researcher
Intended status: Standards Track Quill
Expires: 2 October 2026 AI Research Assistant
31 March 2026
WATCH: A Proposed HTTP Method for Event-Driven Subscriptions
draft-hunt-httpbis-watch-method-00
Abstract
This document proposes the addition of a WATCH method to the
Hypertext Transfer Protocol (HTTP). The WATCH method enables a
client to subscribe to change notifications on a specified resource,
shifting the communication model from client-initiated polling to
server-initiated event delivery.
The proposal includes two companion mechanisms: ALIVE, a client-
initiated heartbeat protocol that maintains subscription validity and
restores economic symmetry between client and server; and UNWATCH, a
clean subscription termination method. Together, these introduce an
event-driven subscription layer into HTTP while preserving the
protocol's existing simplicity and extensibility.
This document incorporates formal terminology, a setup phase with
confirmation handshake, refined jurisdictional compliance guidance,
implementation recommendations, and protocol flow diagrams for all
defined interaction patterns.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 October 2026.
Hunt & Quill Expires 2 October 2026 [Page 1]
Internet-Draft WATCH HTTP Method March 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Polling Tax . . . . . . . . . . . . . . . . . . . . . 4
2.2. Existing Workarounds . . . . . . . . . . . . . . . . . . 5
3. The WATCH Method . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Connection Lifecycle Overview . . . . . . . . . . . . . . 5
3.2. Setup Phase and Confirmation Heartbeat . . . . . . . . . 6
3.2.1. Successful WATCH connection with Setup Phase . . . . 7
3.3. Server-Sent Events Transport . . . . . . . . . . . . . . 8
4. The ALIVE Mechanism . . . . . . . . . . . . . . . . . . . . . 8
4.1. Client-Initiated Heartbeats . . . . . . . . . . . . . . . 8
4.1.1. Heartbeat / Echo maintenance cycle . . . . . . . . . 9
4.2. Economic Equilibrium . . . . . . . . . . . . . . . . . . 9
4.3. Dead Client Eviction . . . . . . . . . . . . . . . . . . 10
4.3.1. Automatic eviction after missed ALIVE deadline . . . 10
5. Dispatches: Server-to-Client Event Delivery . . . . . . . . . 11
5.1. Dispatch delivery with continued WATCH connection . . . . 11
6. UNWATCH: Clean Termination . . . . . . . . . . . . . . . . . 12
6.1. Client-initiated UNWATCH . . . . . . . . . . . . . . . . 12
7. Server-Initiated Termination . . . . . . . . . . . . . . . . 12
7.1. Server-initiated termination with reason . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Cost Asymmetry Attacks . . . . . . . . . . . . . . . . . 13
8.2. Ghost Subscriber Mitigation . . . . . . . . . . . . . . . 14
8.3. Jurisdictional Compliance in Persistent Connections . . . 14
9. Implementation Guidance . . . . . . . . . . . . . . . . . . . 14
9.1. Heartbeat Independence from Dispatch Processing . . . . . 15
9.2. Subscriber State Storage . . . . . . . . . . . . . . . . 15
9.3. ALIVE Interval Sizing . . . . . . . . . . . . . . . . . . 15
10. Comparison with Existing Protocols . . . . . . . . . . . . . 16
11. Reference Implementation . . . . . . . . . . . . . . . . . . 16
12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 17
Hunt & Quill Expires 2 October 2026 [Page 2]
Internet-Draft WATCH HTTP Method March 2026
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Terminology
The following terms are used throughout this document with specific
technical meaning. Each term maps to exactly one concept within the
WATCH protocol.
*WATCH Connection* The persistent client-server relationship
established when a client subscribes to change notifications on a
resource via the WATCH method. A WATCH connection is stateful:
the server maintains subscription state for the duration of the
connection.
*ALIVE Interval* The maximum duration, in seconds, between
consecutive Heartbeats. Established by the server and
communicated to the client during the Setup Phase. The client
MUST send Heartbeats at intervals not exceeding this value to
maintain the WATCH connection.
*Heartbeat* A lightweight message sent by the client to the server
at regular intervals, confirming the client's continued presence
and readiness to receive Dispatches. A Heartbeat carries no body
-- its purpose is purely existential: "I am still here."
*Echo* The server's response to a Heartbeat, confirming that the
WATCH connection remains active and the Heartbeat was recorded.
The Echo contains no new data; it is the Heartbeat reflected back.
This allows the client to verify the server is still honoring the
connection.
*Dispatch* An event payload pushed from the server to the client
when the watched resource changes. A Dispatch is the core
deliverable of the WATCH protocol -- the data the client
subscribed to receive. Dispatches do not affect the WATCH
connection's persistence; the connection continues after each
Dispatch until explicitly terminated.
*Setup Phase* The initialization window between the server's
acceptance of a WATCH request and the activation of the WATCH
connection. During the Setup Phase, the server communicates the
ALIVE Interval and other parameters. The connection activates
only upon receipt of the Confirmation Heartbeat.
*Confirmation Heartbeat* The first Heartbeat sent by the client
Hunt & Quill Expires 2 October 2026 [Page 3]
Internet-Draft WATCH HTTP Method March 2026
after receiving Setup Phase parameters. It confirms the client
has received and accepted the ALIVE Interval terms, and triggers
activation of the WATCH connection. The eviction clock does not
start until this Heartbeat is received.
*Terminology design note:* Each term is intentionally distinct and
non-overlapping. "Heartbeat" and "Echo" form a directional pair
(client-to-server and server-to-client). "Dispatch" is reserved
exclusively for event data delivery, preventing confusion with
protocol maintenance messages.
2. Problem Statement
HTTP's request/response model requires the client to initiate every
interaction. When a client needs to monitor a resource for changes,
the only native mechanism available within the HTTP method
specification is repeated GET requests at regular intervals -- a
pattern known as *polling*. While non-native extensions exist (see
Section 2.2), no standard HTTP method provides subscription
semantics.
2.1. The Polling Tax
In a polling model, each request/response cycle carries the full
weight of HTTP overhead: headers (often 500+ bytes), authentication
tokens, content-type negotiation, payload serialization, and status
codes. The vast majority of these cycles return identical data.
+===========+===============================+==================+
| Axis | Impact | Scale Factor |
+===========+===============================+==================+
| Bandwidth | ~1KB+ overhead per poll, most | N clients x F |
| | returning "no change" | polls/sec x 1KB |
+-----------+-------------------------------+------------------+
| Compute | Server queries data store, | CPU scales |
| | serializes response, executes | linearly with |
| | middleware on every request | client count |
+-----------+-------------------------------+------------------+
| Latency | Changes detected only at next | Faster detection |
| | poll interval; average delay | compounds axes 1 |
| | = interval / 2 | and 2 |
+-----------+-------------------------------+------------------+
Table 1
Hunt & Quill Expires 2 October 2026 [Page 4]
Internet-Draft WATCH HTTP Method March 2026
2.2. Existing Workarounds
Several mechanisms have been developed to work around HTTP's pull-
based limitation. *WebSockets* (RFC 6455) establish a persistent,
full-duplex connection but abandon HTTP request/response semantics
once upgraded. *Server-Sent Events* (SSE) allow server-to-client push
over HTTP but lack a standardized subscription and heartbeat
contract. *Long-polling* holds a connection open until data is
available but reintroduces per-change overhead when the response
triggers a new request. *Webhooks* reverse the flow by having the
server POST to a client-provided URL, but require the client to
operate its own HTTP server.
Each approach solves part of the problem while introducing new
complexity. None provides a native, first-class HTTP verb for
subscription semantics with built-in connection maintenance.
3. The WATCH Method
The WATCH method allows a client to express ongoing interest in a
resource. Upon receiving a WATCH request, the server validates the
request, establishes a subscription, and begins delivering Dispatches
to the client as changes occur.
3.1. Connection Lifecycle Overview
A WATCH connection proceeds through four distinct phases:
Hunt & Quill Expires 2 October 2026 [Page 5]
Internet-Draft WATCH HTTP Method March 2026
+==============+===========+======================================+
| Phase | Initiator | Description |
+==============+===========+======================================+
| *1. | Client | Client sends WATCH /resource with |
| Request* | | authentication credentials |
| | | (transmitted via the standard |
| | | Authorization: Bearer TOKEN header, |
| | | commonly referred to as an API key). |
| | | Server validates credentials, checks |
| | | jurisdictional compliance, and |
| | | registers the pending subscription. |
+--------------+-----------+--------------------------------------+
| *2. Setup* | Server | Server responds with ALIVE Interval, |
| | | subscriber ID, and connection |
| | | parameters. The eviction clock is |
| | | NOT yet running. Client has a setup |
| | | window to configure its Heartbeat |
| | | timer and evaluate the terms. |
+--------------+-----------+--------------------------------------+
| *3. Active* | Both | Client sends Confirmation Heartbeat, |
| | | activating the connection and |
| | | starting the eviction clock. Client |
| | | maintains Heartbeats at the ALIVE |
| | | Interval. Server sends Echoes and |
| | | Dispatches. Connection persists |
| | | through multiple Dispatches. |
+--------------+-----------+--------------------------------------+
| *4. | Either | Connection ends via: client UNWATCH, |
| Termination* | | missed ALIVE deadline (automatic |
| | | eviction), server-initiated |
| | | termination with reason, or |
| | | connection failure. |
+--------------+-----------+--------------------------------------+
Table 2
3.2. Setup Phase and Confirmation Heartbeat
The Setup Phase addresses a critical race condition: without it, the
server would communicate the ALIVE Interval and simultaneously start
the eviction clock. A client receiving a short interval might be
evicted before it can parse the confirmation, configure its timer,
and send its first Heartbeat.
Hunt & Quill Expires 2 October 2026 [Page 6]
Internet-Draft WATCH HTTP Method March 2026
The Setup Phase decouples term delivery from connection activation.
The server sends connection parameters without starting the eviction
clock. The client reads the terms, configures its Heartbeat process,
and sends a Confirmation Heartbeat to signal readiness. Only upon
receipt of this Confirmation Heartbeat does the server consider the
WATCH connection active and begin the eviction clock.
This also gives the client an opportunity to silently reject terms --
if the ALIVE Interval is too aggressive for the client's
capabilities, it simply does not send the Confirmation Heartbeat, and
the connection never activates. No resources are wasted.
3.2.1. Successful WATCH connection with Setup Phase
+==================+=================+===========================+
| Client | Direction | Server |
+==================+=================+===========================+
| WATCH /api/ | WATCH -> | |
| resource, | | |
| Authorization: | | |
| Bearer TOKEN | | |
+------------------+-----------------+---------------------------+
| | <- SETUP | 200 OK, subscriber_id: |
| | | c7f2a91b, alive_interval: |
| | | 15s, status: |
| | | awaiting_confirmation |
+------------------+-----------------+---------------------------+
| | * Setup window | |
| | -- client | |
| | configures | |
| | Heartbeat timer | |
+------------------+-----------------+---------------------------+
| POST /api/alive/ | CONFIRM -> | |
| c7f2a91b | | |
| (Confirmation | | |
| Heartbeat) | | |
+------------------+-----------------+---------------------------+
| | <- ECHO | 200 OK, status: active, |
| | | ALIVE interval: 15s, OK - |
| | | Eviction clock starts |
+------------------+-----------------+---------------------------+
Table 3
Hunt & Quill Expires 2 October 2026 [Page 7]
Internet-Draft WATCH HTTP Method March 2026
3.3. Server-Sent Events Transport
The WATCH response uses the text/event-stream content type (Server-
Sent Events), providing a persistent, unidirectional channel from
server to client over standard HTTP. This transport is used for
Dispatches and server-initiated messages. Heartbeats and Echoes use
separate HTTP request/response cycles on dedicated endpoints.
The authentication token in the Authorization header (commonly
referred to as an API key) is the same credential used throughout the
WATCH connection lifecycle. This token is validated during the
initial WATCH request and is referenced for rate limiting,
subscription caps, and jurisdictional compliance (see Section 8).
``` WATCH /api/tasks/3a8f HTTP/1.1 Host: example.com Authorization:
Bearer TOKEN
HTTP/1.1 200 OK Content-Type: text/event-stream X-Subscriber-Id:
c7f2a91b X-Alive-Interval: 15 ```
4. The ALIVE Mechanism
The ALIVE mechanism makes WATCH economically and operationally
viable. It solves three problems simultaneously: connection liveness
verification, cost asymmetry mitigation, and malicious actor
deterrence.
4.1. Client-Initiated Heartbeats
Unlike traditional heartbeat protocols where the server pings the
client and awaits a response (two messages, server-initiated), ALIVE
shifts initiation to the client (one message, client-initiated). The
client MUST send a Heartbeat to its assigned endpoint at intervals
not exceeding the ALIVE Interval:
``` POST /api/alive/c7f2a91b HTTP/1.1 Host: example.com
HTTP/1.1 200 OK {"status": "alive", "alive_interval_seconds": 15} ```
*Key design decision:* The Heartbeat carries no body. Its purpose
is purely existential. This makes the round-trip cost
approximately 200 bytes, compared to 1KB+ for a typical GET
polling cycle. Even at identical frequencies, Heartbeat-based
maintenance represents an ~80% bandwidth reduction over polling.
Hunt & Quill Expires 2 October 2026 [Page 8]
Internet-Draft WATCH HTTP Method March 2026
4.1.1. Heartbeat / Echo maintenance cycle
+=======================+==============+===============+
| Client | Direction | Server |
+=======================+==============+===============+
| POST /api/alive/ | HEARTBEAT -> | |
| c7f2a91b (empty body) | | |
+-----------------------+--------------+---------------+
| | <- ECHO | 200 OK, ALIVE |
| | | interval: 15s |
+-----------------------+--------------+---------------+
| | * ~15 | |
| | seconds pass | |
+-----------------------+--------------+---------------+
| POST /api/alive/ | HEARTBEAT -> | |
| c7f2a91b (empty body) | | |
+-----------------------+--------------+---------------+
| | <- ECHO | 200 OK, ALIVE |
| | | interval: 15s |
+-----------------------+--------------+---------------+
Table 4
4.2. Economic Equilibrium
In a standard polling model, each request/response cycle imposes
roughly symmetric costs on client and server. WATCH without ALIVE
breaks this symmetry: the client pays once while the server bears all
ongoing costs.
ALIVE restores equilibrium by imposing an ongoing cost on the client
proportional to the number of active WATCH connections. A client
watching one resource sends one Heartbeat per interval. A client
watching one thousand resources sends one thousand Heartbeats per
interval. The cost of maintaining connections scales linearly with
the burden placed on the server.
*Security implication:* A malicious actor attempting to exhaust
server resources by opening many WATCH connections must sustain a
corresponding volume of Heartbeat traffic -- burning their own
bandwidth and compute proportionally to the load they impose.
Hunt & Quill Expires 2 October 2026 [Page 9]
Internet-Draft WATCH HTTP Method March 2026
4.3. Dead Client Eviction
The server maintains a last-seen timestamp for each subscriber. A
background process periodically compares each timestamp against the
current time. If the elapsed time exceeds the ALIVE Interval
multiplied by a configurable grace multiplier (default: 1.5x), the
WATCH connection is terminated and all associated state is released.
+================+============+=======================+=========+
| Parameter | Defined by | Purpose | Example |
+================+============+=======================+=========+
| ALIVE Interval | Server | Maximum seconds | 15s |
| | | between Heartbeats | |
+----------------+------------+-----------------------+---------+
| Grace | Server | Tolerance factor | 1.5x |
| multiplier | | before eviction | |
+----------------+------------+-----------------------+---------+
| Effective | Derived | Interval x multiplier | 22.5s |
| deadline | | = actual cutoff | |
+----------------+------------+-----------------------+---------+
| Eviction sweep | Server | Frequency of the | 5s |
| | | eviction check | |
+----------------+------------+-----------------------+---------+
Table 5
4.3.1. Automatic eviction after missed ALIVE deadline
+==================+=====================+=========================+
| Client | Direction | Server |
+==================+=====================+=========================+
| POST /api/alive/ | HEARTBEAT -> | |
| c7f2a91b | | |
+------------------+---------------------+-------------------------+
| | <- ECHO | 200 OK, ALIVE interval: |
| | | 15s |
+------------------+---------------------+-------------------------+
| | * Client goes | |
| | silent (crash, | |
| | network loss, etc.) | |
+------------------+---------------------+-------------------------+
| | * 22.5s pass with | |
| | no Heartbeat | |
| | received | |
+------------------+---------------------+-------------------------+
| | <- EVICTION | Server ends WATCH |
| | | connection. Subscriber |
| | | state removed |
Hunt & Quill Expires 2 October 2026 [Page 10]
Internet-Draft WATCH HTTP Method March 2026
+------------------+---------------------+-------------------------+
Table 6
5. Dispatches: Server-to-Client Event Delivery
A Dispatch is the core deliverable of the WATCH protocol. When the
watched resource changes, the server pushes an event to all active
subscribers whose ALIVE status is current. The WATCH connection
persists after each Dispatch -- delivering an event does not
terminate the subscription.
A Dispatch payload includes the event type, relevant data, and a
timestamp:
data: { "event": "file_modified", "data": { "file": "config.yaml",
"size_bytes": 2048, "modified_by": "dawson" }, "timestamp":
"2026-03-28T14:32:07Z" }
_Figure 1: Example Dispatch payload_
5.1. Dispatch delivery with continued WATCH connection
+======================+==================+=========================+
| Client | Direction | Server |
+======================+==================+=========================+
| POST /api/alive/ | HEARTBEAT -> | |
| c7f2a91b | | |
+----------------------+------------------+-------------------------+
| | <- ECHO | 200 OK, ALIVE interval: |
| | | 15s |
+----------------------+------------------+-------------------------+
| | * Watched | |
| | resource | |
| | changes | |
+----------------------+------------------+-------------------------+
| | <- DISPATCH | SSE event: |
| | | file_modified, |
| | | config.yaml, 2048 bytes |
+----------------------+------------------+-------------------------+
| | * Connection | |
| | persists -- | |
| | not terminated | |
+----------------------+------------------+-------------------------+
| POST /api/alive/ | HEARTBEAT -> | |
| c7f2a91b (confirms | | |
| client still active) | | |
+----------------------+------------------+-------------------------+
Hunt & Quill Expires 2 October 2026 [Page 11]
Internet-Draft WATCH HTTP Method March 2026
| | <- ECHO | 200 OK, ALIVE interval: |
| | | 15s |
+----------------------+------------------+-------------------------+
Table 7
6. UNWATCH: Clean Termination
The UNWATCH method provides a mechanism for clients to explicitly
terminate WATCH connections. While dead client eviction handles
involuntary disconnections, UNWATCH enables graceful teardown with
immediate resource release.
6.1. Client-initiated UNWATCH
+====================+===========+===============================+
| Client | Direction | Server |
+====================+===========+===============================+
| POST /api/alive/ | HEARTBEAT | |
| c7f2a91b | -> | |
+--------------------+-----------+-------------------------------+
| | <- ECHO | 200 OK, ALIVE interval: 15s |
+--------------------+-----------+-------------------------------+
| POST /api/unwatch/ | UNWATCH | |
| c7f2a91b | -> | |
+--------------------+-----------+-------------------------------+
| | <- | 200 OK, status: unsubscribed. |
| | CONFIRMED | Connection terminated cleanly |
+--------------------+-----------+-------------------------------+
Table 8
7. Server-Initiated Termination
The server MUST be able to terminate WATCH connections unilaterally
for rate limiting, authentication revocation, resource deprecation,
jurisdictional policy changes, or administrative action. In such
cases, the server pushes a final event with type
subscription_terminated and a reason field before closing the event
stream.
data: { "event": "subscription_terminated", "reason":
"rate_limit_exceeded", "message": "Subscription limit reached for
this API key.", "timestamp": "2026-03-28T15:01:44Z" }
_Figure 2: Server-initiated termination payload_
Hunt & Quill Expires 2 October 2026 [Page 12]
Internet-Draft WATCH HTTP Method March 2026
7.1. Server-initiated termination with reason
+=============+=====================+===============================+
| Client | Direction | Server |
+=============+=====================+===============================+
| POST | HEARTBEAT -> | |
| /api/alive/ | | |
| c7f2a91b | | |
+-------------+---------------------+-------------------------------+
| | <- ECHO | 200 OK, ALIVE interval: 15s |
+-------------+---------------------+-------------------------------+
| | * Server decides | |
| | to terminate | |
| | (policy, rate | |
| | limit, etc.) | |
+-------------+---------------------+-------------------------------+
| | <- TERMINATED | SSE: subscription_terminated, |
| | | reason: rate_limit_exceeded, |
| | | "Subscription limit reached." |
+-------------+---------------------+-------------------------------+
| | <- CLOSED | Event stream closed. |
| | | Subscriber state removed |
+-------------+---------------------+-------------------------------+
Table 9
8. Security Considerations
8.1. Cost Asymmetry Attacks
Without ALIVE, WATCH creates an asymmetric cost profile exploitable
for denial-of-service. An attacker subscribing to N resources forces
the server to maintain N subscription states and deliver events to N
queues, at the one-time cost of N WATCH requests. ALIVE mitigates
this by requiring N Heartbeats per ALIVE Interval, making the
attacker's ongoing cost proportional to the server's burden.
Servers SHOULD additionally enforce per-API-key subscription caps
(using the Bearer token from the Authorization header to identify and
rate-limit individual clients), and MAY implement graduated ALIVE
Interval requirements that increase with subscription count.
Hunt & Quill Expires 2 October 2026 [Page 13]
Internet-Draft WATCH HTTP Method March 2026
8.2. Ghost Subscriber Mitigation
Ghost subscribers -- clients that subscribe and then become
unreachable without sending UNWATCH -- represent a resource leak.
The ALIVE eviction mechanism ensures ghost subscribers are
automatically cleaned up within one grace period. Servers MUST NOT
rely solely on TCP connection state for liveness detection, as
intermediary proxies and load balancers may maintain connections
beyond the client's actual availability.
8.3. Jurisdictional Compliance in Persistent Connections
WATCH connections differ fundamentally from transactional GET
requests in their compliance implications. A single GET request is a
discrete act of data transfer: if a server inadvertently serves one
response to a restricted jurisdiction, the exposure is limited to
that single exchange. A WATCH connection, however, is an ongoing
relationship in which *every Dispatch constitutes a separate act of
data transfer* that must independently satisfy applicable legal
frameworks.
This persistent nature means that standard jurisdictional
verification practices -- IP-based geolocation, API key registration
with identity verification, and sanctions list screening -- become
more consequential for WATCH than for transactional verbs. A server
that performs geolocation checks only at request time for GET
requests SHOULD perform them at subscription time for WATCH requests
and SHOULD periodically re-validate for long-lived connections, as
clients may change networks during an active WATCH connection (e.g.
VPN activation, physical travel across jurisdictions).
*Rationale:* Regulations including GDPR, U.S. sanctions law
(OFAC), and national data sovereignty frameworks impose
jurisdiction-dependent constraints on data transfer. A WATCH
connection persisting for hours or days may span regulatory
changes, client network transitions, or evolving sanctions lists
-- making point-in-time validation alone insufficient.
Implementors should leverage existing geolocation infrastructure
rather than introducing new client-declared headers, which are
trivially spoofable and add overhead without meaningfully
improving security.
9. Implementation Guidance
Hunt & Quill Expires 2 October 2026 [Page 14]
Internet-Draft WATCH HTTP Method March 2026
9.1. Heartbeat Independence from Dispatch Processing
Client implementations SHOULD maintain the Heartbeat timer on an
independent thread or asynchronous process that is not blocked by
Dispatch processing. If a Dispatch delivers a large payload that
takes significant time to parse or act upon, a single-threaded client
processing events synchronously may miss its ALIVE deadline and be
evicted.
The Heartbeat is an existential signal, not a data operation. It
should never compete with application logic for execution time.
Implementations that cannot guarantee independent Heartbeat
maintenance should evaluate the server's ALIVE Interval during the
Setup Phase and decline the connection if it is not sustainable.
9.2. Subscriber State Storage
The WATCH protocol requires the server to maintain state for each
active subscriber (subscriber ID, last-seen timestamp, event queue).
The storage mechanism for this state is an implementation concern and
is deliberately left unspecified. Servers MAY use in-memory
structures, in-memory data stores such as Redis, or durable databases
depending on scale and reliability requirements.
Notably, the state lookup burden of WATCH is lighter than that of
polling. In a polling model, the server authenticates and processes
a full API key lookup on every request -- potentially thousands of
times per second per client. With WATCH, full authentication occurs
once (at subscription time), and subsequent state lookups are limited
to Heartbeat checks at the ALIVE Interval. A server handling one
thousand clients polling every second performs one thousand lookups
per second; the same server with WATCH performs approximately sixty-
seven (1000 / 15s interval). Servers operating at scale should
consider durable or distributed state management, but the per-client
overhead is lower than the infrastructure it replaces.
9.3. ALIVE Interval Sizing
Servers should set the ALIVE Interval with consideration for the
expected size and frequency of Dispatches (larger payloads warrant
longer intervals), expected client capabilities (IoT devices may need
longer intervals than desktop applications), and the server's own
resource constraints (shorter intervals detect dead clients faster
but increase Heartbeat traffic).
For most applications, ALIVE Intervals between 10 and 60 seconds
provide a reasonable balance between dead-client detection speed and
Heartbeat overhead.
Hunt & Quill Expires 2 October 2026 [Page 15]
Internet-Draft WATCH HTTP Method March 2026
10. Comparison with Existing Protocols
+===============+==================+===========+=========+=========+
| Feature | WATCH | WebSocket | MQTT | Polling |
+===============+==================+===========+=========+=========+
| HTTP native | Yes | Upgrade | No | Yes |
+---------------+------------------+-----------+---------+---------+
| Server push | Yes | Yes | Yes | No |
+---------------+------------------+-----------+---------+---------+
| Heartbeat | Client-initiated | Ping/Pong | Client | N/A |
| model | | | PINGREQ | |
+---------------+------------------+-----------+---------+---------+
| Bidirectional | No | Yes | Yes | No |
+---------------+------------------+-----------+---------+---------+
| Auto-eviction | Yes | Timeout | Yes | N/A |
+---------------+------------------+-----------+---------+---------+
| REST | Yes | No | No | Yes |
| compatible | | | | |
+---------------+------------------+-----------+---------+---------+
| Cost symmetry | Yes (ALIVE) | Partial | Partial | Yes |
+---------------+------------------+-----------+---------+---------+
| Setup | Yes | Upgrade | CONNECT | No |
| handshake | | | | |
+---------------+------------------+-----------+---------+---------+
Table 10
*Note:* WATCH is most closely analogous to MQTT's subscribe/keep-
alive pattern but operates natively within the HTTP ecosystem,
preserving compatibility with existing infrastructure (proxies,
load balancers, CDNs, API gateways) without requiring protocol
upgrades or separate broker services.
11. Reference Implementation
A reference implementation has been developed to validate the
protocol design described in this draft. The implementation consists
of two Python programs, available at https://github.com/dawsonhunt/
watch-http-method :
*watch_server.py* -- A Flask-based HTTP server implementing WATCH,
ALIVE, and UNWATCH endpoints with filesystem monitoring (via the
watchdog library), background eviction, a real-time web dashboard,
and the complete Setup Phase including Confirmation Heartbeat
handling.
Hunt & Quill Expires 2 October 2026 [Page 16]
Internet-Draft WATCH HTTP Method March 2026
*watch_client.py* -- A command-line client that subscribes to the
server's event stream, displays incoming Dispatches, and maintains
the Heartbeat on an independent background thread. A --skip-alive
flag demonstrates automatic eviction when Heartbeats cease.
The implementation demonstrates the complete WATCH connection
lifecycle: request, Setup Phase, Confirmation Heartbeat, active
Dispatch delivery, and termination via both UNWATCH and eviction.
12. Conclusion
The WATCH method addresses a fundamental gap in the HTTP
specification: the absence of a native subscription mechanism. By
pairing server-push event delivery with client-initiated Heartbeats,
the proposal achieves event-driven efficiency while maintaining the
economic equilibrium and security properties that make HTTP's
stateless model robust.
The key insight underlying this proposal is that introducing
statefulness into a stateless protocol is viable if and only if the
cost of maintaining that state is distributed fairly between client
and server. ALIVE achieves this through what we term *subscription
as economic contract*: the client pays ongoing costs (Heartbeats)
proportional to the obligations it imposes on the server, and failure
to pay results in automatic eviction. The Setup Phase ensures both
parties agree to terms before resources are committed, and elevated
jurisdictional scrutiny addresses the regulatory exposure inherent in
persistent data relationships.
The authors invite discussion, review, and critique from the IETF
community, and welcome collaboration on formal specification of the
WATCH, ALIVE, and UNWATCH semantics toward an eventual Proposed
Standard.
Authors' Addresses
Dawson Hunt
Independent Researcher
Houston, TX
Email: dawson.t.hunt@gmail.com
Quill
AI Research Assistant
Email: quill.research@yahoo.com
Hunt & Quill Expires 2 October 2026 [Page 17]