Ok, found the answer: the header view class can also be a UICollectionViewListCell, which provides the exact same mechanism as UITableViewHeaderFooterView.

Interesting, I did not know this header. It seems to do exactly what you would want: give the server a chance to reject the request before the upload of the body is even started. I added the header to the URLRequest, but that did not fix the problem. But that might very well be a problem on the server side. I'm still investigating that. So I guess that would be our best shot? Trying to make our server support this header?

It is not. At least not to my knowledge, and I don't see the "Transfer-Encoding: chunked" header on the server side (I don't know if I would though, or if the framework we are using on the server (Spring Boot) handles that transparently). Would that be a possible solution? If so, how would I enable chunked transfer encoding? I tried to just add the Transfer-Encoding header to the URLRequest, but that didn't seem to do anything.

Yes!

Correct! This is a normal call to URLSession.upload(for:from:delegate) while the app is in the foreground, not a background session. The URLSession is created by us, but with the URLSessionConfiguration.default and only with a custom user agent string. Everything else is left as is. I might also add that the server is also our own software. The way it works is the server receives the data until the allowed maximum is reached, then it sends the response and closes the connection, while the network layer is still trying to send the remaining data. But again, I could see in the diagnostics log that the response is received and read.

As suggested by https://twitter.com/hunter/status/1513960632059510784 I just deleted my local provisioning profile files which forced Xcode to generate them again and this fixed the issue for me.