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

On 29.10.2024 06:25, Michael Toomim wrote:
> 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.

If that was true, a 404 or a 410 shouldn't be a 4xx either.

I would think an existing 4xx could be used here (depending on the
reason why the resource was not found), together with an error document
(as per RFC....).


> 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. :)
> ...

That might take some time.

Best regards, Julian

Received on Tuesday, 29 October 2024 06:01:16 UTC