Skip to content
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

Feature/tus #10

Merged
merged 5 commits into from
Oct 21, 2015
Merged

Feature/tus #10

merged 5 commits into from
Oct 21, 2015

Conversation

choonkeat
Copy link
Owner

Implements http://tus.io/ open protocol for resumable uploads support

cc @khangtoh

slow but allows switching of servers between requests
Attache.cache.write to create file when current_offset errors - compatiblity fix for tus.js client
@choonkeat
Copy link
Owner Author

FYI @winston TUS upload protocol is more suitable for API integration, e.g. mobile app upload big file over flaky network

The only difference with TUS here is that the PATCH response comes with a JSON that the client app should read and store.

@choonkeat
Copy link
Owner Author

FYI @zamakkat @shinnyx for clients uploading over unreliable networks, can use the tus.io protocol (which will be 1.0 soonish) on /tus/files endpoint for resumable upload

choonkeat added a commit that referenced this pull request Oct 21, 2015
@choonkeat choonkeat merged commit 3be2c4e into master Oct 21, 2015
@choonkeat choonkeat deleted the feature/tus branch October 21, 2015 03:01
@winston
Copy link

winston commented Oct 21, 2015

Just to clarify, basically we are implementing the TUS standard/protocol here (headers) right?

@choonkeat
Copy link
Owner Author

Yes, but

  • TUS protocol is only available at /tus/files end point; does not affect the regular /upload endpoint
  • according to protocol, the PATCH response is just HTTP 200 and Offset header (both of which we are doing). But on top of it, we're also returning the json body like what we do for regular attache file upload. This should be a compatible extension to the existing protocol, and I suspect/hope is something not difficult for a client to implement

@winston
Copy link

winston commented Oct 21, 2015

This should be a compatible extension to the existing protocol, and I suspect/hope is something not difficult for a client to implement

Ah yes. There's always the client side story to this too.. Keep forgetting that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants