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

tus-uploady: Support destination headers & clarify readme #60

Closed
kevbost opened this issue Jul 5, 2020 · 3 comments · Fixed by #61
Closed

tus-uploady: Support destination headers & clarify readme #60

kevbost opened this issue Jul 5, 2020 · 3 comments · Fixed by #61
Labels
bug Something isn't working docs Improvements or additions to documentation

Comments

@kevbost
Copy link

kevbost commented Jul 5, 2020

I noticed while trying to implement this package that the tus-uploady readme states:

# packages/ui/tus-uploady/README.md L63
It also supports the Upload-Metadata header and will turn the destination params prop into the metadata key/value.

Headers aren't passed through with the prop destination={{url: "https://my-server", headers: {"x-custom": "123"}}} even though the Readme states all UploadOptions props can be passed to TusUploady.

I would suggest either allowing custom headers or updating the Readme to make the params object more clear in the props table.

I'd also suggest making it clear that you don't have to pre-encode the Upload-Metadata values in Base64 as is required in the TUS Docs concerning the Upload-Metadata format. The destination params: {key: 'value'} is automatically converted to Upload-Metadata: key dmFsdWU=.

@yoavniran
Copy link
Collaborator

hey @kevbost

re headers - this is unexpected. destination.headers should be passed afaik. Sounds like a bug, ill check.

re params - these are generic params that are either sent as form data (when used with normal Uploady or Chunked-Uploady) or converted to the TUS Upload-Metadata header. What do you feel is missing?

re params - encoding. Will do.

thanks

@yoavniran yoavniran added bug Something isn't working docs Improvements or additions to documentation labels Jul 5, 2020
@kevbost
Copy link
Author

kevbost commented Jul 5, 2020

I don't feel anything else is missing, I'm only suggesting that the docs on the topic need to be a little more explicit. Thank you!

@yoavniran
Copy link
Collaborator

@kevbost Seeing as TUS uploads first start with a create call and then subsequent chunks each get their own request, youd expect the custom header to be sent along with the create call, I presume?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working docs Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants