sorry when writing then I should be able to reach the server and get a server response I meant to say then I shouldn't be able to reach the server and get a server response

Eskimo, thanks for your answers. There are several follow up questions I wanted to ask after I did some testing, especially around the concept that the resumeData becomes invalid when I restart the request, for cases where our app crashes after resuming an upload and thus having only the previously saved resume data and not a fresh version. Unfortunately, when I went to go test some of these scenarios, I discovered that as of last week, CloudFlare's proxy service no longer allows the 104 intermediate response to go through, and thus I'm never getting any resumeData. We've been working with our CloudFlare representative last week and this week, but don't yet have an answer on why that happened, or if they could allow the 104s again. (They never fully worked, because cloudflare always timed out the connection about a minute after the 104s came through, but we were cancelling the upload as soon as we got the 104 so we could get some resume data and save it on disk, and then restarting from resumeData immediately, and that was working fine for months during feature development.) Do you know of any proxy services which do the support Apple's implemented variant of the tusd protocol (i.e. with the intermediate 104 response)? Can Apple somehow influence CloudFlare to support Apple's implemented variant of the tusd protocol? It's been released on iOS devices for over a year. I'm happy to go sit on the sidewalk across the street from their headquarters holding up a sign that says "Support 104s" if it will help. Is there a way to force the resume manually if the device can't get the 104 intermediate response from the server? We're doing PUTs not POSTs and we already have a unique identifier, so from our perspective we could provide the Location header value pre-calculated when we start the upload initially, but I don't know how to synthesize resumeData with that value. It looks like you've carefully neutered NSKeyedArchiver's ability to read the data blob which I could maybe fix, but it also looks like you maybe even encrypted the original request headers in the data blob, so I'm assuming we wouldn't be able to install the correct encryption keys to provide you with a synthesized resumeData? Is there a way to get resume data if the 104 response is final, and not intermediate? In our testing the answer seemed to be 'no'.