Hello!
My company uses TUSKit with authorization. We provide auth in headers, and as of 3.7.0 are taking advantage of the just-in-time setting of headers (thanks!).
I'd like to request a further enhancement to get notified of errors that will be automatically retried. In our case these are sometimes 401's or 404s, which won't be recovered by simply retrying. These are typically uploads that were enqueued in a previous app session, and are being resumed automatically with expired/invalidated credentials, or against a url that no longer exists.
In the case of 401s, we'd like to await the result of a token refresh before allowing the retries to continue. In the case of 404s we'd like to cancel the upload.
Is that something we could accomplish through a new delegate callback (like uploadShouldRetryAfterError:client:continuationBlock:), or is this something you've considered and intentionally ruled out? If so do you have a recommendation on how to avoid the doomed retries?
Thanks, Andrew
Hello!
My company uses TUSKit with authorization. We provide auth in headers, and as of 3.7.0 are taking advantage of the just-in-time setting of headers (thanks!).
I'd like to request a further enhancement to get notified of errors that will be automatically retried. In our case these are sometimes 401's or 404s, which won't be recovered by simply retrying. These are typically uploads that were enqueued in a previous app session, and are being resumed automatically with expired/invalidated credentials, or against a url that no longer exists.
In the case of 401s, we'd like to await the result of a token refresh before allowing the retries to continue. In the case of 404s we'd like to cancel the upload.
Is that something we could accomplish through a new delegate callback (like
uploadShouldRetryAfterError:client:continuationBlock:), or is this something you've considered and intentionally ruled out? If so do you have a recommendation on how to avoid the doomed retries?Thanks, Andrew