Response headers in didFinishUpload delegate + data race fix (supersedes #167) - #231
Conversation
|
Hi @LefterisHaritou, In order to merge this PR I will need to have the commits created with a verified signature. You can find more information about this here: https://docs.github.com/en/authentication/managing-commit-signature-verification |
UploadDataTask now unpacks the upload result as (offset, responseHeaders) and saves responseHeaders into UploadMetadata. UploadMetadata decoding was made tolerant by using decodeIfPresent for responseHeaders so older metadata without that key won't fail decoding. This propagates server response headers into metadata and avoids crashes when the field is missing.
fd7aff9 to
86b9c81
Compare
Should be ok now @donnywals ! Thanks |
Hey @donnywals. Any other blockers from merging this? |
Summary
Adds HTTP response header support to the
didFinishUploaddelegate callback, and fixes a data race inTUSAPI.This continues and fixes the work started in #167 (by @srvarma7), rebased on top of the latest
main(including the progress-wiring changes from #228).What's included
didFinishUpload(id:url:context:client:responseHeaders:)delegate method surfaces the server's response headers. The previous signature is kept as a deprecated compatibility shim that forwards to the new method, so existing conformers keep working without changes.HTTPURLResponse+Headersextension to extract headers into a[String: String]dictionary.UploadDataTasknow unpacks the upload result as(offset, responseHeaders)and storesresponseHeadersonUploadMetadata.UploadMetadatadecodesresponseHeaderswithdecodeIfPresent, so older persisted metadata without that key won't fail to decode.TUSAPIcallback handling was adjusted to avoid a data race on the shared callback state.Relationship to #167
This supersedes #167 with the missing fix applied and a clean rebase onto current
main. Happy to close #167 in favor of this if preferred.Testing
swift buildsucceeds (only the expected deprecation warning from the intentional compatibility shim).