- From: Michael Toomim <toomim@gmail.com>
- Date: Mon, 28 Oct 2024 22:25:05 -0700
- To: Braid <braid-http@googlegroups.com>, HTTP Working Group <ietf-http-wg@w3.org>, Lisa Dusseault <lisa@dtinit.org>
- Message-ID: <70e31c02-1ccc-4fbe-ac10-a4e8c8d01873@gmail.com>
Hey all, we made progress on HTTP Resource Versioning, and published a new draft -02 last Monday. In particular, Mark Nottingham and Lisa Dusseault asked how the *Version:* and *Parents:* headers would interact with legacy intermediaries that don't know their semantics, and what the spec should tell us to do as countermeasures. To address this, we implemented tests with real intermediaries (using the excellent cache-tests.fyi, which made it very easy) and are hosting the tests and their results here: https://cache-tests.braid.org The first section of these tests shows how legacy caches behave. You'll notice they fail precisely where Mark predicted— a legacy cache will re-use a response with the wrong Version: or Parents: header. It doesn't include the header in its cache key. However, this is quite easy to fix by adding "Vary: version, parents" to the response. The second section of tests shows the behavior of caches when this header is added. This header tells caches to add the Version and Parents headers to their cache keys, and this is enough for them all to distinguish versions correctly. This results in caches that can even store multiple versions of a resource (see the third section), which means we can probably use existing caches to cache the entire edit history of a document. This will be sweet for collaborative editing. We also explained how to detect legacy caches on the network. Read about these things in Section 4 of the new draft spec: Section 4: Versioning through Intermediaries <https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions-02#section-4> Lisa also asked what happens when a client requests a version that the server has stopped storing. We propose a "309 Version Unknown Here" status code in Section 2.6 <https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions#section-2.6> for a server to say that it doesn't know a version. This isn't a client error (4xx-series response) or a server error (5xx-series response). We are calling it a 3xx-series (redirection and further action required) because further action could retrieve a resource's history, although the mechanisms for doing so are beyond the scope of this draft. I would love feedback on these updates. Meanwhile, I am still working through the other excellent questions you all have already provided. I expect to give Julian a response on WebDAV soon. :) Thank you all! Cheers and Braids, Michael -------- Forwarded Message -------- Subject: New Version Notification for draft-toomim-httpbis-versions-02.txt Date: Mon, 21 Oct 2024 16:46:42 -0700 From: internet-drafts@ietf.org To: Michael Toomim <toomim@gmail.com> A new version of Internet-Draft draft-toomim-httpbis-versions-02.txt has been successfully submitted by Michael Toomim and posted to the IETF repository. Name: draft-toomim-httpbis-versions Revision: 02 Title: HTTP Resource Versioning Date: 2024-10-21 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/archive/id/draft-toomim-httpbis-versions-02.txt Status: https://datatracker.ietf.org/doc/draft-toomim-httpbis-versions/ HTMLized: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions Diff: https://author-tools.ietf.org/iddiff?url2=draft-toomim-httpbis-versions-02 Abstract: HTTP resources change over time. Each change to a resource creates a new "version" of its state. HTTP systems often need a way to identify, read, write, navigate, and/or merge these versions, in order to implement cache consistency, create history archives, settle race conditions, request incremental updates to resources, interpret incremental updates to versions, or implement distributed collaborative editing algorithms. This document analyzes existing methods of versioning in HTTP, highlights limitations, and sketches a more general versioning approach that can enable new use-cases for HTTP. An upgrade path for legacy intermediaries is provided. The IETF Secretariat
Received on Tuesday, 29 October 2024 05:25:11 UTC