Disallow offsets smaller than uploaded size

[Acconut]

Citing the current spec for the PATCH request:

The Offset value SHOULD be equal, but MAY also be smaller than the current offset of the resource, and servers MUST handle PATCH operations containing the same data at the same absolute offsets idempotently.

In v0.2.2 of tus offsets smaller then the offset of the resource are accepted allowing clients to change already uploaded chunks of the resource. While this makes sense in some rare cases it hardens the server implementations. The problem is that the server must wait until everything is uploaded to start processing the resource because the client may change parts of the file. For example, a server may start converting a big video file right from the start allowing faster conversion and better resource usage.

Another point to consider is that streaming downloads of uploads are impossible if offsets smaller than the amount of already uploaded bytes.

If the client knows that parts of the file will change in the future they shouldn't be uploaded in the first place and only in their final state. The server should not to take care of that.

I suggest to change to specification to disallow this behaviour. In cases where the clients sends such values the request should be rejected returning a 409 Conflict.

[kvz]

Marius clarified two concerns that I had about this elsewhere, will try to summarize here

What about failed checksums?

Those will be discarded/reverted, the offset won't be impacted

What about uploading chunks in parallel?

The offset cannot fall below what's been uploaded of each specified offset

+1 for me

[qsorix]

+1

Any concerns I have are solvable by hypothetical extensions, so I don't see why not.

[tim-kos]

+1

I am all for making server implementations easier and this seems to be a sensible way to do so.

[Acconut]

Merged in #56.