Fwd: New Version Notification for draft-toomim-httpbis-versions-02.txt

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