tus 1.0 resumable uploads
CoreUpload ships a zero-dependency tus 1.0 client (Core + Creation + Termination extensions) and a filesystem-backed TusStorage service. Interop with tusd, uppy-companion, or any tus 1.0-compliant server. Works out of the box against the built-in endpoint - no extra DI wiring needed.
What you should see: uploads negotiate the tus 1.0 protocol — a creation POST then PATCH requests with Upload-Offset headers (visible in the network tab). Interrupts resume from the server-confirmed offset.
Drag & drop files here, or paste from clipboard
Resume behaviour: if you reload the page during an upload, the resumed task does a
HEAD on the stored tus URL, reads the server's current Upload-Offset, and PATCHes from there. No bytes are re-uploaded.
Client config
CoreUpload.create('#uploader', {
uploadUrl: '/api/upload/upload',
strategy: 'tus',
chunkSize: 5 * 1024 * 1024, // PATCH chunk size persistState: true,
persistAdapter: 'indexeddb' // tusEndpoint defaults to `{uploadUrl base}/tus` - override if needed: // tusEndpoint: 'https://your-tusd-host/files/'
}); Server side
CoreUpload's default endpoint map registers the tus routes automatically - no additional code required beyond app.MapCoreUploadEndpoints().
// Program.cs - already in place in CoreUpload's default pipeline
builder.Services.AddCoreUpload();
// TusStorage is registered automatically inside AddCoreUpload().
var app = builder.Build();
app.MapCoreUploadEndpoints(); // maps /tus POST/HEAD/PATCH/DELETE/OPTIONS Wire protocol (tus 1.0.0)
OPTIONS /tus-> capabilities (Tus-Version: 1.0.0,Tus-Extension: creation,termination)POST /tus->201+Location: /tus/{id}(Creation extension)HEAD /tus/{id}-> currentUpload-Offset(used for resume)PATCH /tus/{id}<- bytes withContent-Type: application/offset+octet-streamDELETE /tus/{id}-> cleanup on cancel / fatal error (Termination extension)
Third-party server interop
The same client works against any tus 1.0 server - just point tusEndpoint at it. Tested against tusd and uppy-companion.