Draft Version Identification

[guoye-zhang]

Borrowed from the HTTP/3 draft

quicwg/base-drafts@c1a0d99#diff-c7364e57fd3b825f8342d91eabf4fa844f1c26127970ccb1af9a1a16a6598165

[smatsson]

Does this only apply to the 104 and not the other responses? I can see the benefit of adding it to all responses if there are breaking changes between two draft versions.

[guoye-zhang]

I think it's more important for feature detection to signal the version since it can fallback to a regular non-resumable upload.

For explicit uses of the resumable upload protocol, finding out version mismatch is too late because it can only lead to failure. Experimental deployments should use different URLs for different draft versions to ensure compatibility. E.g. https://example.com/draft-v1/upload

[Acconut]

Interesting proposal. I had thought about a draft version identification as being sent from the client to the server, so the server knows using which version the request should be handled.

In your PR, the identifier is intended, so the client can error out if the server implements a wrong draft version. Is this correct?

[guoye-zhang]

I suppose that a request header works too. This is specific to feature detection so incompatible versions ignore each other’s feature detection message

[guoye-zhang]

Oh I think a request header is better, since the final version won’t need to worry about this header any more. I’ll update the PR

[guoye-zhang]

Updated to have Upload-Draft-Version in both request and 104 response. (It's the only way RFC client and server implementations without this logic can inter-op with draft implementations)

[Acconut]

Sounds great! Thanks for the update!