Conversation
|
Thank you very much for this PR! It looks interesting. Let me know once it is ready for a review! |
Sorry this took so long. Need some help with code reviews and testing this |
|
Thank you! I will try to review this in the next two weeks! |
partially copied from tus#347
Acconut
left a comment
There was a problem hiding this comment.
Thank you again for this incredible work. I left some comments to your code :)
lib/upload.js
Outdated
| Checksum = require('./browser/extensions/checksum').default | ||
| } | ||
| this._checksum = new Checksum( | ||
| Checksum.supportedAlogrithms.find((supportedAlgo) => supportedAlgorithms.includes(supportedAlgo)), |
There was a problem hiding this comment.
What does this check do? The combination of find and includes looks suspicious.
There was a problem hiding this comment.
I was trying to fetch the supported algorithms from the server and see if one of them matches one of the supported algorithms on the client. If we're saying client and server have agreed upon an algorithm from the get go, then we can skip this OPTIONS call and let client just configure the algorithm in options.
lib/upload.js
Outdated
| if (value === null) { | ||
| if (this.options.enableChecksum) { | ||
| if (this._checksum) { | ||
| value.arrayBuffer().then((chunkBuffer) => { |
There was a problem hiding this comment.
Could this entire if block be merged with the last else block? They seem very similar and would avoid some duplication.
There was a problem hiding this comment.
Not sure how this might reduce the duplication as one is async. I've removed one outer if condition. Is that okay?
|
Thank you for the review. Please have a look @Acconut, I see there are conflicts. I'll try to address them, might need help |
|
@Acconut please have another look at this |
|
Can I work on this? I may have a need to have this working in the future. |
|
Apologies, I wasn't aware that @manohar27 performed changes after my last review! @mahyarmirrashed Feel free to continue, but did you have anything specific in mind that needs to be changed here? |
|
@Acconut I have not taken a close look at the PR. Just wondering if there is a way that I can contribute/continue if needed. I might have a need for the checksum extension in about a month. |
Acconut
left a comment
There was a problem hiding this comment.
Again, thanks very much for the work and apologies for losing track of this! I left a few comments if you or anybody else is interested in continuing this. It's on a very good track and we just need a few adjustments to get this ready.
| "forceAllTransforms": true | ||
| } ] | ||
| ], | ||
| "plugins": ["@babel/transform-runtime"] |
There was a problem hiding this comment.
Could you explain why this plugin is necessary?
| endpoint, | ||
| chunkSize, | ||
| retryDelays: [0, 1000, 3000, 5000], | ||
| checksumAlgo: "SHA-256", |
There was a problem hiding this comment.
The tus protocol itself uses a naming conventional like sha1, so I would prefer if we could also use sha256 here.
| class Checksum { | ||
| static supportedAlgorithms = ['SHA-1', 'SHA-256', 'SHA-384', 'SHA-512']; | ||
|
|
||
| constructor (algo = 'SHA-256') { |
There was a problem hiding this comment.
I don't think we need a default value here. If no algorithm or an unsupported one is supplied, we can just error out.
| } | ||
|
|
||
| export interface Checksum { | ||
| getHexDigest(): string; |
There was a problem hiding this comment.
The Upload-Checksum encodes the checksum in base64, instead of hexadecimal. So we need to adjust the interface itself as well as the implementations. I am also wondering if the checksum provider should just return a byte array and let the main tus-js-client logic take care of encoding it into the right format.
| } | ||
|
|
||
| export interface Checksum { | ||
| getHexDigest(): string; |
There was a problem hiding this comment.
The inferface definition is also missing the data argument.
| urlStorage?: UrlStorage | ||
| fileReader?: FileReader | ||
| httpStack?: HttpStack | ||
| checksum?: Checksum; |
There was a problem hiding this comment.
I would prefer a name that aligns with fileReader for the checksum as well. Maybe we can call this option checksumProvider and the classes also ChecksumGenerator.
"Digest" would also likely be a better fit than checksum, although the protocol specification does not use that term, unfortunately.
| }) | ||
| .catch((err) => { | ||
| log(err) | ||
| throw err |
There was a problem hiding this comment.
For error handling, please use _emitError.
| }) | ||
| }) | ||
|
|
||
| describe('#Checksum', () => { |
There was a problem hiding this comment.
We would also need a full test to ensure the checksum header is added to the actual requests. Such a test should be placed in test-common, which includes tests shared between browsers and Node.js.
Let me know if you need help with getting this running :)
| causingError: Error | ||
| } | ||
|
|
||
| export interface Checksum { |
There was a problem hiding this comment.
Once we have finalized the interface and options, we should also add documentation. But that can wait for now.
|
I'll try to do some work on this in the new year. By the way @Acconut , should there be any documentation changes with this? Something to let people know how to use this feature? |
Yes, once we have settled on how the feature's API should work, we can also address the documentation.
Great! I am looking forward to your contributions :) |

Adds Checksum Extension support.
This is work in progress.
Uses SubtleCrypto on browser and crypto library on nodejs