tusd
tusd copied to clipboard
HEAD Request Handling
HEAD Request Handling
Currently majority of CDN services are not responding for HEAD Request properly. Converting HEAD requests to GET and tus
servers returns 204 and uploads starts from the begging...!
Why tus
can't use GET
Method instead of HEAD
??
Setup details Please provide following details, if applicable to your situation:
- Operating System: Linux
- Used tusd version: 1.0
- Used tusd data storage: AWS S3
- Used tusd configuration: [-s3-bucket,-s3-endpoint,-s3-object-prefix,-max-size,-timeout,-port,-hooks-http,-hooks-http-retry,-hooks-http-backoff,-hooks-enabled-events ,-behind-proxy]
- Used tus client library: tus-js-client
Why tus can't use GET Method instead of HEAD??
The are mainly two reasons:
- tusd is designed for uploads and not for serving files. I would not recommend using tusd for serving content or even behind a CDN. You should use a proper server for this job.
- The tus protocol does not need to fetch the content of a file but only the metadata associated with an upload. Therefore HEAD requests fit semantically better than GET requests.
Okay.
How the tusd, server identify files while resuming uploads after a long time? What are the parameters used to identify the upload.?
What are the parameters used to identify the upload.?
Each upload has an ID that is included in the URL that the HEAD/PATCH requests are sent to.
This was I did.
- Uploaded a file with name
Falcon F16.mp4
- I've refreshed the page when upload at 30%
- Again I stated the upload, it is started from 30%
How it is possible. with out url-with-id
?
What are the parameters
used to identify the upload.?
Ah, I see what your question is. tus-js-client uses a combination of file name, file size, modification date and mime type to see if the file was already uploaded (or began to upload) before: https://github.com/tus/tus-js-client/blob/master/lib/browser/fingerprint.js#L17-L24
It's not a perfect heuristic but has served us very well in the past.