All Classes and Interfaces

Class
Description
Common abstract super class to implement service that use the disk file system
Abstract request handler to add tus extension values to the correct header
Abstract RequestHandler implementation that contains the common functionality
 
Enum that contains all supported checksum algorithms The names of the checksum algorithms MUST only consist of ASCII characters with the modification that uppercase characters are excluded.
Exception thrown when the client sends a request for a checksum algorithm we do not support
The Server MAY respond with one of the following status code: 400 Bad Request if the checksum algorithm is not supported by the server
The Client and the Server MAY implement and use this extension to verify data integrity of each PATCH request.
The Tus-Checksum-Algorithm header MUST be included in the response to an OPTIONS request.
 
This extension can be used to concatenate multiple uploads into a single one enabling Clients to perform parallel uploads and to upload non-contiguous chunks.
The response to a HEAD request for a upload SHOULD NOT contain the Upload-Offset header unless the concatenation has been successfully finished.
If the Server supports this extension, it MUST add concatenation to the Tus-Extension header.
The Server MUST acknowledge a successful upload creation with the 201 Created status.
Validate that the given upload length in combination with the bytes we already received, does not exceed the declared initial length on upload creation.
All PATCH requests MUST use Content-Type: application/offset+octet-stream.
The Tus-Resumable header MUST be included in every request and response except for OPTIONS requests.
A HEAD request is used to determine the offset at which the upload should be continued.
An OPTIONS request MAY be used to gather information about the Server’s current configuration.
The Server SHOULD accept PATCH requests against any upload URL and apply the bytes contained in the message at the given offset specified by the Upload-Offset header.
The core protocol describes how to resume an interrupted upload.
The Client and the Server SHOULD implement the upload creation extension.
A HEAD request can be used to retrieve the metadata that was supplied at creation.
The Client and the Server SHOULD implement the upload creation extension.
Upload-Defer-Length: 1 if upload size is not known at the time.
The Server MUST acknowledge a successful upload creation with the 201 Created status.
UploadLockingService implementation that uses the file system for implementing locking
File locking can also apply to shared network drives.
Implementation of UploadStorageService that implements storage on disk.
Some Tus clients also send GET request to retrieve the uploaded content.
Send the uploaded bytes of finished uploads
Add our download extension the Tus-Extension header
The Server MAY remove unfinished uploads once they expire.
The Server MAY remove unfinished uploads once they expire.
The Upload-Expires response header indicates the time after which the unfinished upload expires.
Directory stream filter that only accepts uploads that are still in progress and expired
Upload locking implementation using the file system file locking mechanism.
Transparently coalesces chunks of a HTTP stream that uses Transfer-Encoding chunked.
Class that will hold constants for all HTTP headers relevant to the tus v1.0.0 protocol
Class that represents a HTTP method.
Class to validate if the current HTTP method is valid
If the resource is not found, the Server SHOULD return either the 404 Not Found, 410 Gone or 403 Forbidden status without the Upload-Offset header.
 
Exception thrown when the request has an invalid content type.
Exception thrown when the Upload-Concat header contains an ID which is not valid.
Exception thrown when receiving a request with a tus protocol version we do not support
The Tus-Resumable header MUST be included in every request and response except for OPTIONS requests.
Exception thrown when no valid Upload-Length or Upload-Defer-Length header is found
 
Exception thrown when the given upload length exceeds or internally defined maximum
The Client MUST NOT include the Upload-Length header in the upload creation.
Validate that the IDs specified in the Upload-Concat header map to an existing upload
The Server MUST respond with the 403 Forbidden status to PATCH requests against a upload URL and MUST NOT modify the or its partial uploads.
The Server MUST respond with the 403 Forbidden status to PATCH requests against a upload URL
An empty POST request is used to create a new upload resource.
Exception thrown when a POST request was received on an invalid URI
The Client MUST send a POST request against a known upload creation URL to request a new upload resource.
 
Interface for request validators
Exception thrown when the disk storage path cannot be read or created.
When receiving a DELETE request for an existing upload the Server SHOULD free associated resources and MUST respond with the 204 No Content status confirming that the upload was terminated.
This extension defines a way for the Client to terminate completed and unfinished uploads allowing the Server to free up used resources.
Add our download extension the Tus-Extension header
Combined implementation of UploadStorageService and UploadLockingService.
Alternative UploadIdFactory implementation that uses the current system time to generate ID's.
Super class for exception in the tus protocol
Interface that represents an extension in the tus protocol
Helper class that implements the server side tus v1.0.0 upload protocol
Class that will validate if the tus version in the request corresponds to our implementation version
The Tus-Resumable header MUST be included in every request and response except for OPTIONS requests.
 
HttpServletResponseWrapper to capture header values set on the current HttpServletResponse.
Exception thrown when we receive a HTTP request with a method name that we do not support
 
Exception thrown when the client provided checksum does not match the checksum calculated by the server
Interface for a service that is able to concatenate partial uploads into a concatenated upload
The request MUST include one of the following headers: a) Upload-Length to indicate the size of an entire upload in bytes. b) Upload-Defer-Length: 1 if upload size is not known at the time.
The unique identifier of an upload process in the tus protocol
Interface for a factory that can create unique upload IDs.
Class that contains all metadata on an upload process.
Exception thrown when accessing an upload that is still in progress and this is not supported by the operation
Enumeration class that enumerates all input streams associated with with given list of uploads
Exception thrown when the Client includes the Upload-Length header in the upload creation.
If the length of the upload exceeds the maximum, which MAY be specified using the Tus-Max-Size header, the Server MUST respond with the 413 Request Entity Too Large status.
Interface that represents a lock on an upload
Service interface that can lock a specific upload so that it cannot be modified by other requests/threads.
Exception thrown when the given upload ID was not found
If the resource is not found, the Server SHOULD return either the 404 Not Found, 410 Gone or 403 Forbidden status without the Upload-Offset header.
If the offsets do not match, the Server MUST respond with the 409 Conflict status without modifying the upload resource.
The Upload-Offset header’s value MUST be equal to the current offset of the resource.
Interface to a service that is able to store the (partially) uploaded files.
Enum that lists all the possible upload types in the tus protocol
Utility class that contains various static helper methods
Factory to create unique upload IDs.
UploadConcatenationService implementation that uses the file system to keep track of concatenated uploads.