- From: Michael Sweet <msweet@msweet.org>
- Date: Thu, 10 Oct 2024 11:49:05 -0400
- To: Ben Schwartz <bemasc@meta.com>
- Cc: Watson Ladd <watsonbladd@gmail.com>, Michael Toomim <toomim@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Ben, > On Oct 10, 2024, at 10:13 AM, Ben Schwartz <bemasc@meta.com> wrote: > ... > I believe we can accomplish this while staying close to familiar HTTP territory. For example, we could extend If-Modified-Since (and If-None-Match) with a new parameter, "wait=?1". When the client sends this parameter, it tells the server to block instead of returning "304 (Not Modified)". This allows cacheable long-polling for updates, with graceful degradation to short polling if the server/gateway ignores this parameter. Further optimizations to reduce delay and data transfer can potentially be added on top of this mechanism. > ... This is effectively what IPP does for "pull" notifications (RFC 3996) - the Client specifies whether it wants to wait for events from the Printer, and the Printer can return its complete response at any time with a hint to the Client of how many seconds to wait until it sends another request. *If* you were to adopt such a scheme for HTTP in general, I personally would opt for a pair of new headers: one request header to specify whether to wait for updates and one response header with the hint for when to check for more updates. If you have a server or proxy that doesn't support the new headers then the behavior gracefully reverts to a regular conditional request/response. And it works the same for all versions of HTTP... ________________________ Michael Sweet
Received on Thursday, 10 October 2024 15:49:21 UTC