- From: Martin Thomson <mt@lowentropy.net>
- Date: Fri, 11 Oct 2024 08:48:59 +1100
- To: "Michael Sweet" <msweet@msweet.org>, "Ben Schwartz" <bemasc@meta.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Fri, Oct 11, 2024, at 02:49, Michael Sweet wrote: >> 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. > > *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. https://www.rfc-editor.org/rfc/rfc7240#section-4.3 defined Prefer: wait=4 for the first.
Received on Thursday, 10 October 2024 21:49:24 UTC