Get historical versions: Weird fallback

[josephg]

If a server supports returning some historical versions, but not all of them, the spec says this:

   If a GET request contains a Version header:

     - If the server does not support historical versions, it MAY ignore
       the Version header and respond as usual, but MUST NOT include the
       Version header in its response.

This is weird. Like, if I ask for version 10, and the server says no, it instead returns the content of version 20? I guess this is so it gracefully degrades to the current HTTP behaviour. But I think we should explicitly recommend servers return some 4xx error code in this case instead of returning the current document version.

The problem of course is that this would break existing caches - which would see a GET then a 4xx response and invalidate their cache of the document contents. I'd love to hear more thoughts about the best way to handle this.

[toomim]

What is the problem with returning the current version? I guess there's a little more network overhead?

We do also specify using the 410 Gone error code later in the spec. Maybe we should RECOMMEND that it returns that code here as well?

[toomim]

Actually, I think we already kinda do specify using 410 Gone for this:

3.5.  Errors

   If a server has dropped the history that a client requests, the
   server can return a 410 GONE response, to tell the client "sorry, I
   don't have the history necessary to synchronize with you."

However, this is only stated in section 3 (Subscriptions) whereas the request you're looking at is in section 2. Maybe we should move this error stuff up to section 2?

[josephg]

Yeah I agree. Either it should be moved to section 2 or section 2 should reference the error response from 3.5.

What is the problem with returning the current version? I guess there's a little more network overhead?

It just seems weird. I can't think of any cases when I explicitly request a historical version of a document (eg for a timeline) and it would be acceptable to replace the historical documents with brand new documents. I think an error would be a much more appropriate response here.

[mitar]

The problem of course is that this would break existing caches - which would see a GET then a 4xx response and invalidate their cache of the document contents. I'd love to hear more thoughts about the best way to handle this.

I think this is solved by Vary header having Version?

[toomim]

It just seems weird. I can't think of any cases when I explicitly request a historical version of a document (eg for a timeline) and it would be acceptable to replace the historical documents with brand new documents. I think an error would be a much more appropriate response here.

Well, we can't force any legacy server to suddenly return error codes when it sees headers that it didn't know about when it was implemented.

But we can recommend that servers return errors, and that clients be tolerant of servers that do not send errors.