Client disconnect detection
One of the core features of tusdotnet is knowing when a client has disconnected so that held resources can be released. A client disconnect can be detected by either the client telling the server that it disconnected or that a timeout occurs. The timeout settings in tusdotnet previously depended on a reverse proxy signaling a timeout or that Kestrel was configured correctly. Starting with the release tusdotnet contains its own logic for handling timeouts which are more efficient than relying on a global request timeout. The new timeout mechanism determines how long tusdotnet will wait to receive data from the client and not how long the entire request takes, meaning that it will need to wait a shorter time before disconnecting a slow client and unlocking the file.
The client read timeout is configured using the ClientReadTimeout property on the DefaultTusConfiguration. The default value is set to a conservative 60 seconds to not interfere with existing timeout settings.
Lock on HEAD requests
HEAD requests to determine the upload offset for the client was previously a non-locking action. This version changes this behavior to locking. This increases stability in cases where data is in transfer but has not yet reached the server when the client disconnects and reconnects. In earlier versions this would cause the wrong offset to be retrieved. The client would then continue from the wrong offset causing an offset mismatch error when trying to patch the data.
Compatibility with other implementations
Response code for locked operations have been changed from 409 Conflict to 423 Locked to better conform to how clients and other servers are implemented.
Exceptions thrown from OnFileCompleteAsync were swallowed for creation-with-upload
This causes issues in the case when an exception is thrown from OnFileCompleteAsync as the exception would be swallowed and a 201 Created would be returned to the client instead of the exception. See #211 for details.
What's Changed
Full Changelog: 2.7.2...2.8
