-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PATCH creation #98
Comments
This is how our uploads works: async function upload (file) {
const tag = hash({
name: file.name.toLowerCase()
size: file.size,
lastModified: file.lastModified
})
let position = 0
while (position < file.size) {
const res = await window
.fetch(`file/${tag}.${file.name.split('.').pop().toLowerCase()}`, {
method: 'PATCH',
headers: {
'upload-offset': position,
'upload-length': file.size,
'upload-type': file.type,
'upload-expires': new Date(Date.now() + 4 * 24 * 60 * 60 * 1000).toUTCString(),
'content-type': 'application/offset+octet-stream'
},
body: file.slice(position, position + 128e6)
})
if (res.status === 204 || res.status === 409) {
position = parseInt(res.headers.get('upload-offset'), 10)
} else {
throw res
}
}
} |
Do you mind explaining why you decided to create the upload URL on the client side? Did you have a look at the upcoming Creation With Upload extension (see #88)? It adds a way to provide a part of the file in the initial |
We are almost able to support the tus protocol. However, since we generate a unique id on client side we do not want to create an upload resource using a POST call. Since several clients might start uploading (creating) the same id, which in our case should be allowed.
Could sending PATCH to a resource that does not yet exist, create it? I think this aligns with the HTTP specification and the tus protocol does not seem to either allow or disallow it?
https://tools.ietf.org/html/rfc5789
The text was updated successfully, but these errors were encountered: