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

On 10/28/24 11:01 PM, Julian Reschke wrote:
>> 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 agree that either 3xx or 4xx could work. I considered using a 4xx when 
writing the draft.

The reason I chose 3xx is that there is a strong sense in which "Version 
Unknown Here" is not an error, but is just a redirection. We are 
building for a P2P world in which we expect peers to independently 
choose how much history to store, and which versions to drop, knowing 
that other peers probably store them. So the process of requesting a 
version in a P2P network can involve asking around at lots of peers 
before you find the old history you are looking for. Thus, the request 
involves lots of redirection as it pokes around the network, which makes 
"Version Unknown Here" a redirection like 301, 302, 303, 305, 306, 307, 
and 308. The request does not conceptually finish until the client finds 
the version, or gives up.

On the other hand, both 404 and 410 are unambiguous errors — the client 
is requesting something that plainly does not exist. The request ends as 
soon as the 4xx error is received by the client. Caches can store 4xx 
responses (except 407).

A 3xx says "I don't know, ask around." A 4xx says "I *know* that this 
doesn't exist."

So it fits the semantics of 3xx redirection to me, rather than 4xx, but 
I can see the argument both ways.

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

I suppose it depends on how much detail we go into. Here's an overview.

1. WebDAV only supports centralized versioning.

    WebDAV's basic model of LOCK/UNLOCK, and CHECKIN/CHECKOUT/UNCHECKOUT
    assumes a central server controlling a lock, that clients must check
    stuff out from, and check in to.

    This makes it incompatible with distributed versioning systems, such
    as git, CRDT, and OT, which limits the applicability of the WebDAV spec.

    It also adds unnecessary complexity. Distributed versioning does not
    need these methods, and does not need other methods like MKCOL. This
    unnecessary complexity has limited adoption of WebDAV.

2. WebDAV takes up URL space by requiring each version of a resource to 
have a URL.

    This was how we differentiate WebDAV in the spec:

        1.1.3.  Versioning encoded within URLs

            In practice, application programmers tend to encode versions
        within
            URLs:

        https://unpkg.com/braid-text@0.0.18/index.js

            This approach is common in API versioning (e.g.,
        /api/v1/resource).
            However, it has several drawbacks:

            1. It loses the semantics of a "resource changing over time."
               Instead, it creates multiple version resources for every
        single
               logical resource.

            2. It necessitates additional standards for version history
        on top of
               URLs (e.g., Memento, WebDAV, Link Relations for Versioning
               [RFC5829]).

            3. Given a URL, we still need a standard way to extract the
        version
               itself, get the previous and next version(s), and
        understand the
               format of the version(s) (e.g., major.minor.patch).

            4. This approach can lead to URI proliferation, potentially
        impacting
               caching strategies and SEO.

            5. It may complicate content negotiation and RESTful design
               principles.

            The choice to embed versions into URLs can be useful, but
        carries
            with it additional tradeoffs.  A versioning system does not
        need to
            depend on allocating a URL for each version; but could be
        compatible
            with doing so.

3. WebDAV has unnecessary complexity for simple tasks.

    Let's say you GET a resource /foo with WebDAV, and now you want to
    know what version it is. This requires two more requests: a PROPFIND
    to get the version-history URL, and then another PROPFIND on that
    URL to get the list of URLs. Then you have to parse the XML, and
    figure out which of those URLs is the most recent, and then assume
    that it's the same one as the resource you just did the GET for. If
    you're not sure, you might have to request that URL explicitly, and
    compare its value to the one you got.

    That's 3 or 4 requests, total. And 2 of them involve digging through
    XML with a new PROPFIND method.

    With this Versioning spec, you get the current version in the
    original GET request automatically. It's in the Version: header.

    See the example requests and responses here:
    https://news.ycombinator.com/item?id=40481003

Do you think I'm missing anything important here?

Thanks!

Michael