There are many crashes at iOS16 in CFURLRequestSetURL. The crash log Crashed: com.apple.NSURLSession-work 0 CFNetwork 0x18578 CFURLRequestSetURL + 14416 1 libdispatch.dylib 0x24b4 _dispatch_call_block_and_release + 32 2 libdispatch.dylib 0x3fdc _dispatch_client_callout + 20 3 libdispatch.dylib 0xb694 _dispatch_lane_serial_drain + 672 4 libdispatch.dylib 0xc214 _dispatch_lane_invoke + 436 5 libdispatch.dylib 0x16e10 _dispatch_workloop_worker_thread + 652 6 libsystem_pthread.dylib 0xdf8 _pthread_wqthread + 288 7 libsystem_pthread.dylib 0xb98 start_wqthread + 8

I have an app which uses URLSession-based networking and URLCache for storing network requests on disk. I noticed that when the storage size of URLCache reaches the diskCapacity, the eviction strategy seems to be to remove all entries, which is a problem in my use case. So I decided to write an URLCache subclass which would provide a custom storage for cached responses and which would implement LRU eviction strategy with better control. As URLCache's documentation states, subclassing for this purpose should be supported: The URLCache class is meant to be used as-is, but you can subclass it when you have specific needs. For example, you might want to screen which responses are cached, or reimplement the storage mechanism for security or other reasons. However, I ran into problems with trying to use this new URLCache subclass with URLSession networking. I have a test resource which I fetch using HTTP GET. The response headers contain: Cache-Control: public, max-age=30 Etag: <some-value> When using the standard, non-subclassed URLCache, the first request loads the data from network as expected (verified with HTTP proxy). The second request doesn't go to the network, if done within first 30 seconds, as expected. Subsequent requests after 30 seconds cause conditional GETs with Etag, as expected. When using a URLCache subclass, all requests load the data from network - max-age doesn't seem to matter, and no conditional GETs are made. It seems that the URLCache does something special to the CachedURLResponse instances after they're loaded from its internal storage, and this something affects how URLSession handles the HTTP caching logic. What am I missing here? I've written a very minimal URLCache implementation to demonstrate this problem. This class stores and loads CachedURLResponse instances using NSKeyedArchiver / NSKeyedUnarchiver, and it supports only zero or one response. Note that there are no calls to super - this is by design, since I want to use my own storage. Here's the implementation: class CustomURLCache: URLCache { let cachedResponseFileURL = URL(filePath: NSTemporaryDirectory().appending("entry.data")) // MARK: Internal storage func read() -> CachedURLResponse? { guard let data = try? Data(contentsOf: cachedResponseFileURL) else { return nil } return try! NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data) as! CachedURLResponse } func store(_ cachedResponse: CachedURLResponse) { try! (try! NSKeyedArchiver.archivedData(withRootObject: cachedResponse, requiringSecureCoding: false)).write(to: cachedResponseFileURL) } // MARK: URLCache Overrides override func cachedResponse(for request: URLRequest) -> CachedURLResponse? { read() } override func getCachedResponse(for dataTask: URLSessionDataTask, completionHandler: @escaping (CachedURLResponse?) -> Void) { guard let response = read() else { completionHandler(nil) return } completionHandler(response) } override func storeCachedResponse(_ cachedResponse: CachedURLResponse, for request: URLRequest) { store(cachedResponse) } override func storeCachedResponse(_ cachedResponse: CachedURLResponse, for dataTask: URLSessionDataTask) { store(cachedResponse) } } My test case: func test() { let useEvictingCache = false let config = URLSessionConfiguration.default if useEvictingCache { config.urlCache = CustomURLCache() } else { config.urlCache = URLCache(memoryCapacity: 0, diskCapacity: 1024 * 1024 * 100) } self.urlSession = URLSession(configuration: config) let url = URL(string: "https://example.com/my-test-resource")! self.urlSession?.dataTask(with: URLRequest(url: url), completionHandler: { data, response, error in if let data { print("GOT DATA with \(data.count) bytes") } else if let error { print("GOT ERROR \(error)") } }).resume() }

We use Rest API POST call to connect to some external Https endpoints. This worked for years, but not clients on 16.2 have the problem that out of a sudden the calls are blocked. Then nothing works, and our app thinks it's offline (for this call) but it's not offline since other services are. The only wat to fix this is to Restart the app fully. Then it's working for some while. Is their something changed in IOS 16, that its blocking an endpoint when you do to many calls? It's for prints and pin payment, so we do calls like this continuously. Here the error we get when it goes wrong: Failed with error sessionTaskFailed(error: Error Domain=NSURLErrorDomain Code=-1009 "De internetverbinding is offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x282afcc30 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, _kCFStreamErrorCodeKey=50, First we did do the call like this: urlRequest.setValue(self.getToken(), forHTTPHeaderField: "Authorization") urlRequest.setValue("text/plain", forHTTPHeaderField: "Content-Type") urlRequest.addValue("application/json", forHTTPHeaderField: "Accept") urlRequest.httpMethod = "POST" urlRequest.httpBody = request.data let config = URLSessionConfiguration.default config.timeoutIntervalForRequest = TimeInterval(5) config.timeoutIntervalForResource = TimeInterval(5) config.waitsForConnectivity = false let session = URLSession(configuration: config) let task = session.dataTask(with: urlRequest) { responseData, response, error in var isPosted = false if let err = error { Logger.debug("AWS-Api: \(request.identifer) - Failed with " + "error \(err), retrying after few seconds") var newReq = request newReq.noRetry += 1 self.addRequest(newReq) } else if let resData = responseData, let res = response { isPosted = self.processAWSResponse(request.identifer, data: resData, postData: request.data, response: res) } session.invalidateAndCancel() return promise(.success(isPosted)) } task.resume() } To debug we also updated it and use Alomfire. But unfortunately both dont work. In IOS 15 no problems are their. All the endpoints are https://

memory leak in when working with URLSession webSocketTask introductory command line app, mac os Ventura 13.2.1 the first leak is fixed on the URLSessionWebSocketDelegate delegate func urlSession(_ session: URLSession, webSocketTask: URLSessionWebSocketTask, didOpenWithProtocol protocol: String?) further when calling receive closures or through func receive() async throws -> URLSessionWebSocketTask.Message the system is constantly leaking memory In order to understand how sad everything is, I recommend opening 20-50 sockets in parallel for large data streams, as an example, financial exchanges per day of work, 0.2-1 gigabytes of leakage will accumulate there is one suggestion, maybe it will help fix the bug, it is connected with another leak in the system that appears in the absence of user interactions, example if we create 20-50 swiftUI labels and start updating them fast enough 5-10 times per second and stop interacting with the mouse, keyboard and touchbar, we will get a memory leak when the old label data is not destroyed by the system - and without touching the keyboard, the mouse in an hour several gigabytes will leak us, then if you move the mouse or press a button on the keyboard, the system will clear the memory

I’m working on an independent watchOS app which is primarily designed to to collect and periodically send location updates to a server. The UI features a toggle that allows the user to turn this capability on or off at their discretion. The typical use case scenario would be for the user to turn the toggle on in the morning, put the app in the background and then go about their day. Given the limitations and restrictions regarding background execution on watchOS, in an ideal situation, I would be able to upload the stored location updates about every 15-20 minutes. With an active complication on the watch face, it’s my understanding that this should be possible. I’ve implemented background app refresh and indeed, I do see this reliably being triggered every 15-20 minutes or so. In my handle(_:) method, I process the WKApplicationRefreshBackgroundTask like this: func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) { backgroundTasks.forEach { task in switch task { case let appRefreshBackgroundTask as WKApplicationRefreshBackgroundTask: // start background URL session to upload data; watchOS will perform the request in a separate process so that it will continue to run even if our app gets // terminated; when the system is done transferring data, it will call this method again and backgroundTasks will contain an instance of // WKURLSessionRefreshBackgroundTask which will be processed below startBackgroundURLSessionUploadTask() scheduleNextBackgroundAppRefresh() appRefreshBackgroundTask.setTaskCompletedWithSnapshot(false) case let urlSessionTask as WKURLSessionRefreshBackgroundTask: // add urlSessionTask to the pendingURLSessionRefreshBackgroundTasks array so we keep a reference to it; when the system completes the upload and // informs us via a URL session delegate method callback, then we will retrieve urlSessionTask from the pendingURLSessionRefreshBackgroundTasks array // and call .setTaskCompletedWithSnapshot(_:) on it pendingURLSessionRefreshBackgroundTasks.append(urlSessionTask) // create another background URL session using the background task’s sessionIdentifier and specify our extension as the session’s delegate; using the same // identifier to create a second URL session allows the system to connect the session to the upload that it performed for us in another process let configuration = URLSessionConfiguration.background(withIdentifier: urlSessionTask.sessionIdentifier) let _ = URLSession(configuration: configuration, delegate: self, delegateQueue: nil) default: task.setTaskCompletedWithSnapshot(false) } } } And here is how I'm creating and starting the background URL session upload task: func startBackgroundURLSessionUploadTask() { // 1. check to see that we have locations to report; otherwise, just return // 2. serialize the locations into a temporary file // 3. create the background upload task let configuration = URLSessionConfiguration.background(withIdentifier: Constants.backgroundUploadIdentifier) configuration.isDiscretionary = false configuration.sessionSendsLaunchEvents = true let backgroundUrlSession = URLSession(configuration: configuration, delegate: self, delegateQueue: nil) let request: URLRequest = createURLRequest() // this is a POST request let backgroundUrlSessionUploadTask = backgroundUrlSession.uploadTask(with: request, fromFile: tempFileUrl) backgroundUrlSessionUploadTask.countOfBytesClientExpectsToSend = Int64(serializedData.count) // on average, this is ~1.5 KB backgroundUrlSessionUploadTask.countOfBytesClientExpectsToReceive = Int64(50) // approximate size of server response backgroundUrlSessionUploadTask.resume() } Note that I'm not setting the .earliestBeginDate property on the backgroundUrlSessionUploadTask because I'd like the upload to start as soon as possible without any delay. Also, this same class (my WatchKit application delegate) conforms to URLSessionTaskDelegate and I have implemented urlSession(_:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:) and urlSession(_:task:didCompleteWithError:). In my testing (on an actual Apple Watch Ultra running watchOS 9.3.1), I've observed that when the system performs the background app refresh, I always receive a callback to myhandle(_:) method. But when I start the background URL session upload task (in startBackgroundURLSessionUploadTask()), I was expecting that when the upload completes, I'd receive another call to myhandle(_:) method with an instance of WKURLSessionRefreshBackgroundTask but this doesn't seem to happen consistently. Sometimes I do see it but other times, I don't and when I don't, the data doesn't seem to be getting uploaded. On a side note, most of the time, startBackgroundURLSessionUploadTask() gets called as a result of my code handling a background app refresh task. But when the user turns off the toggle in the UI and I stop the location updates, I need to report any stored locations at that time and so I call startBackgroundURLSessionUploadTask() to do that. In that specific case, the upload seems to work 100% of the time but I definitely don't see a callback to my handle(_:) method when this occurs. Am I wrong in expecting that I should always be getting a callback to handle(_:) when a background URL session upload task completes? If so, under what circumstances should this occur? Thanks very much!

Hello, I am getting crashes on iOS 16 devices only regarding CFNetwork. Below is the full crash report. I am not able to reproduce it on my end. I've attached the .txt crash log below and also posted it below. CFNetworkCrashLog.txt Any help is appreciated, thank you! Crashed: com.apple.NSXPCConnection.m-user.com.apple.nsurlsessiond EXC_BREAKPOINT 0x00000001cfbbecec 7 Foundation 0x42054 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 Foundation 0x41f3c -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 9 UIKitCore 0x4d66a4 -[UIEventFetcher threadMain] + 436 10 Foundation 0x5b518 __NSThread__start__ + 716 11 libsystem_pthread.dylib 0x16cc _pthread_start + 148 12 libsystem_pthread.dylib 0xba4 thread_start + 8 com.google.firebase.crashlytics.MachExceptionServer 0 App 0x387cfc FIRCLSProcessRecordAllThreads + 393 (FIRCLSProcess.c:393) 1 App 0x3880dc FIRCLSProcessRecordAllThreads + 424 (FIRCLSProcess.c:424) 2 App 0x395be0 FIRCLSHandler + 34 (FIRCLSHandler.m:34) 3 App 0x396400 FIRCLSMachExceptionServer + 521 (FIRCLSMachException.c:521) 4 libsystem_pthread.dylib 0x16cc _pthread_start + 148 5 libsystem_pthread.dylib 0xba4 thread_start + 8 GAIThread 0 libsystem_kernel.dylib 0xda8 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x13a1c mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x13c5c mach_msg_overwrite + 388 3 libsystem_kernel.dylib 0x12ec mach_msg + 24 4 CoreFoundation 0x7aac4 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x7bd08 __CFRunLoopRun + 1232 6 CoreFoundation 0x80eb0 CFRunLoopRunSpecific + 612 7 Foundation 0x42054 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 Foundation 0x41ee8 -[NSRunLoop(NSRunLoop) run] + 64 9 App 0x563d00 +[GAI threadMain:] + 64 10 Foundation 0x5b518 __NSThread__start__ + 716 11 libsystem_pthread.dylib 0x16cc _pthread_start + 148 12 libsystem_pthread.dylib 0xba4 thread_start + 8 com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0xda8 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x13a1c mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x13c5c mach_msg_overwrite + 388 3 libsystem_kernel.dylib 0x12ec mach_msg + 24 4 CoreFoundation 0x7aac4 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x7bd08 __CFRunLoopRun + 1232 6 CoreFoundation 0x80eb0 CFRunLoopRunSpecific + 612 7 CFNetwork 0x257ff0 _CFURLStorageSessionDisableCache + 61088 8 Foundation 0x5b518 __NSThread__start__ + 716 9 libsystem_pthread.dylib 0x16cc _pthread_start + 148 10 libsystem_pthread.dylib 0xba4 thread_start + 8 CommandHandler 0 libsystem_kernel.dylib 0xda8 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x13a1c mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x13c5c mach_msg_overwrite + 388 3 libsystem_kernel.dylib 0x12ec mach_msg + 24 4 CaptiveNetwork 0x9d78 ConnectionGetCommandInfo + 160 5 CaptiveNetwork 0x7c54 __add_signal_port_source_block_invoke_2 + 244 6 libdispatch.dylib 0x3f88 _dispatch_client_callout + 20 7 libdispatch.dylib 0x7418 _dispatch_continuation_pop + 504 8 libdispatch.dylib 0x1aa58 _dispatch_source_invoke + 1588 9 libdispatch.dylib 0xb518 _dispatch_lane_serial_drain + 376 10 libdispatch.dylib 0xc18c _dispatch_lane_invoke + 384 11 libdispatch.dylib 0x16e10 _dispatch_workloop_worker_thread + 652 12 libsystem_pthread.dylib 0xdf8 _pthread_wqthread + 288 13 libsystem_pthread.dylib 0xb98 start_wqthread + 8 Thread 0 libsystem_kernel.dylib 0x12b0 __workq_kernreturn + 8 1 libsystem_pthread.dylib 0xe44 _pthread_wqthread + 364 2 libsystem_pthread.dylib 0xb98 start_wqthread + 8 Thread 0 libsystem_pthread.dylib 0xb90 start_wqthread + 254 Crashed: com.apple.NSXPCConnection.m-user.com.apple.nsurlsessiond 0 libobjc.A.dylib 0x6cec objc_opt_respondsToSelector + 48 1 libsystem_trace.dylib 0x6480 _os_log_fmt_flatten_object + 248 2 libsystem_trace.dylib 0x41a0 _os_log_impl_flatten_and_send + 1864 3 libsystem_trace.dylib 0x21bc _os_log + 152 4 libsystem_trace.dylib 0x7840 _os_log_impl + 24 5 CFNetwork 0x10dc08 _CFURLConnectionCopyTimingData + 34880 6 Foundation 0x64b620 message_handler_error + 360 7 libxpc.dylib 0x1179c _xpc_connection_call_event_handler + 152 8 libxpc.dylib 0x11be8 _xpc_connection_mach_event + 1020 9 libdispatch.dylib 0x4048 _dispatch_client_callout4 + 20 10 libdispatch.dylib 0x24104 _dispatch_mach_cancel_invoke + 128 11 libdispatch.dylib 0x21720 _dispatch_mach_invoke + 916 12 libdispatch.dylib 0xb518 _dispatch_lane_serial_drain + 376 13 libdispatch.dylib 0xc1c0 _dispatch_lane_invoke + 436 14 libdispatch.dylib 0x16e10 _dispatch_workloop_worker_thread + 652 15 libsystem_pthread.dylib 0xdf8 _pthread_wqthread + 288 16 libsystem_pthread.dylib 0xb98 start_wqthread + 8

To download files, we have two NSURLSession objects. One configured for foreground downloads and one for background downloads. Initially, we download user-requested files in the foreground using downloadTaskWithRequest, because foreground downloads are faster than background downloads. We then also start a background task for each download using beginBackgroundTaskWithName:expirationHandler:. This background task's expiration handler starts a background download if the download didn't complete in the foreground. It cancels the foreground download with resume data using cancelByProducingResumeData. A background download task is then started using downloadTaskWithResumeData. Now, testing has shown that background download tasks resume correctly (the urlSession(_:downloadTask:didResumeAtOffset:expectedTotalBytes:) callback is called by iOS) if the background task is started immediately. However, iOS can decide to start these background download tasks later. As a sidenote, the isDiscretionary property of our background download session is set to the default, which should be false. The issue we have is that background downloads that are resumed several minutes (6,5 minutes in the session I'm currently looking at) after their original foreground download was cancelled, are not resumed properly. They download the remaining part of the file, but the first part that was downloaded in the foreground is lost. What could have happened? Perhaps the temporary file has been deleted in the meantime? Is there some way to maintain this file or detect this case?

Hi, I've read over many of the helpful posts on background modes ([1], [2], and responses to my thread [3]) but am encountering something that doesn't quite line up with my understanding. Background My app is using Bluetooth background mode in order to receive data from a peripheral periodically and then perform a network request (eventually, this will involve two network requests, one of them being an upload of audio, which will be a much larger transfer of up to a couple hundred KB, possibly requiring m4a compression first). In background mode, all the Bluetooth messages (currently a small string) are received reliably. The app is woken up and from my understanding, given some time to run in the background. I perform a POST request using URLSession.shared.dataTask(with: request). Problem Encountered These often succeed but sporadically fail with a timeout in background mode and with the error message "connection was lost". Furthermore, nearly every request in background mode is associated with some sort of connection error that appears in the log. Given that many of the requests still succeed, I'm not sure what to make of these. I see a variety of different ones. For example: Case 1: 2023-05-23 16:33:49.428668-0700 ChatGPT for Monocle[4775:1088487] [connection] nw_read_request_report [C1] Receive failed with error "Socket is not connected" 2023-05-23 16:33:49.429633-0700 ChatGPT for Monocle[4775:1088487] [connection] nw_read_request_report [C1] Receive failed with error "Socket is not connected" 2023-05-23 16:33:49.431677-0700 ChatGPT for Monocle[4775:1088487] [connection] nw_read_request_report [C1] Receive failed with error "Socket is not connected" 2023-05-23 16:33:49.440358-0700 ChatGPT for Monocle[4775:1088487] [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-0151a6eeef6cab8c6b53cceead6cada7cf118a4e] unable to request outbound data 2023-05-23 16:33:49.440528-0700 ChatGPT for Monocle[4775:1088487] [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-0151a6eeef6cab8c6b53cceead6cada7cf118a4e] unable to request outbound data 2023-05-23 16:33:49.440640-0700 ChatGPT for Monocle[4775:1088487] [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-0151a6eeef6cab8c6b53cceead6cada7cf118a4e] unable to request outbound data 2023-05-23 16:33:49.440784-0700 ChatGPT for Monocle[4775:1088487] [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-0151a6eeef6cab8c6b53cceead6cada7cf118a4e] unable to request outbound data 2023-05-23 16:33:49.441459-0700 ChatGPT for Monocle[4775:1088487] [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-0151a6eeef6cab8c6b53cceead6cada7cf118a4e] unable to request outbound data 2023-05-23 16:33:49.441684-0700 ChatGPT for Monocle[4775:1088487] [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-0151a6eeef6cab8c6b53cceead6cada7cf118a4e] unable to request outbound data 2023-05-23 16:33:49.445598-0700 ChatGPT for Monocle[4775:1088487] [connection] nw_endpoint_handler_add_write_request [C1.1.1.1 104.18.6.192:443 failed channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns)] Cannot send after flow table is released 2023-05-23 16:33:49.445773-0700 ChatGPT for Monocle[4775:1088487] [connection] nw_write_request_report [C1] Send failed with error "Socket is not connected" 2023-05-23 16:33:49.446925-0700 ChatGPT for Monocle[4775:1088487] Connection 1: received failure notification 2023-05-23 16:33:49.447348-0700 ChatGPT for Monocle[4775:1088487] Connection 1: write error 1:57 2023-05-23 16:33:49.464436-0700 ChatGPT for Monocle[4775:1088487] [connection] nw_endpoint_handler_unregister_context [C1.1.1.1 104.18.6.192:443 failed channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns)] Cannot unregister after flow table is released 2023-05-23 16:33:49.464974-0700 ChatGPT for Monocle[4775:1088487] [] nw_endpoint_flow_fillout_data_transfer_snapshot copy_info() returned NULL Case 2: 2023-05-23 16:34:09.422783-0700 ChatGPT for Monocle[4775:1088784] [connection] nw_read_request_report [C3] Receive failed with error "Socket is not connected" 2023-05-23 16:34:09.423511-0700 ChatGPT for Monocle[4775:1088784] [connection] nw_read_request_report [C3] Receive failed with error "Socket is not connected" 2023-05-23 16:34:09.425478-0700 ChatGPT for Monocle[4775:1088784] [connection] nw_read_request_report [C3] Receive failed with error "Socket is not connected" 2023-05-23 16:34:09.434263-0700 ChatGPT for Monocle[4775:1088784] [quic] quic_conn_send_frames_for_key_state_block_invoke [C3.1.1.1:2] [-01809801f02b5c3795812501322b6f9d3c91236f] unable to request outbound data The code that is generating these requests is fairly straightforward: public func send(query: String, apiKey: String, model: String, completion: @escaping (String, ChatGPTError?) -> Void) { let requestHeader = [ "Authorization": "Bearer \(apiKey)", "Content-Type": "application/json" ] _payload["model"] = model if var messages = _payload["messages"] as? [[String: String]] { messages.append([ "role": "user", "content": "\(query)" ]) _payload["messages"] = messages } let jsonPayload = try? JSONSerialization.data(withJSONObject: _payload) let url = URL(string: "https://api.openai.com/v1/chat/completions")! var request = URLRequest(url: url) request.httpMethod = "POST" request.allHTTPHeaderFields = requestHeader request.httpBody = jsonPayload _task = URLSession.shared.dataTask(with: request) { data, response, error in if let error = error { DispatchQueue.main.async { completion("", ChatGPTError.networkRequestFailed(error: error)) } return } if let data = data { let (contentError, response) = self.extractContent(from: data) if let contentError = contentError { DispatchQueue.main.async { completion("", contentError) } } else if let response = response { DispatchQueue.main.async { completion(response, nil) } } return } DispatchQueue.main.async { completion("", ChatGPTError.responsePayloadParseError) } } _task?.resume() } Questions Is there any way to make this process more reliable? I assume the error messages are meaningful and should not be ignored. If not, will I end up encountering issues when trying to upload larger payloads? Thank you! -- B.

We receive bad address error Error: （kNWErrorDomainPOSIX 错误 14 - Bad address）,未能完成该操作。 Environment: iPhone 8#iOS#13.6# from completion handler in -[NSURLSessionWebSocketTask receiveMessageWithCompletionHandler:] or -[NSURLSessionWebSocketTask sendMessage:completionHandler:] I'm not quit sure which one since their reporting error from same function in our code :( =================================================== I was search information about #define EFAULT 14 /* Bad address */ and socket, most of content telling me that we did not pass buffer to socket function properly. But NSURLSessionWebSocketTask has no method for me to manipulate underlying socket. =================================================== We can not reproduce this error since it was reported from user device. Any possible reason that make this error happen?

Hi community: I'm trying to discover how the dnssec api works, but I cannot get a sample that works with it. Maybe I'm wrong with the requirements; if it is please, clarify it to me. So what I understood. All DNS zones (which respond to TLS listed here https://manage.whois.com/kb/answer/2998) have a way to say, hey I'm who I am. So without any extra configuration, we can use the new API. Is that right? So the code that I did, see the next code let urlSession = URLSession.init(configuration: .ephemeral) if #available(iOS 16.0, *) { urlSession.configuration.requiresDNSSECValidation = true } var request = URLRequest(url: URL(string: "https://www.apple.com")!) if #available(iOS 16.1, *) { request.requiresDNSSECValidation = true } cancellable = urlSession .dataTaskPublisher(for: request) .retryWithDelay(retries: 2, delay: 2, scheduler: DispatchQueue.global(qos: .background)) .sink(receiveCompletion: { result in if case let .failure(error) = result { print("Error \(error)") } }, receiveValue: { (data: Data, response: URLResponse) in print("It Works") Result: Task finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001, UserInfo={_kCFStreamErrorCodeKey=-2102, NSUnderlyingError=0x600003d86130 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <040AB9E7-EFCB-4072-8357-E0149769BB9D>.<2>, _NSURLErrorRelatedURLSessionTaskErrorKey=(``` "LocalDataTask <040AB9E7-EFCB-4072-8357-E0149769BB9D>.<2>" ), NSErrorFailingURLStringKey=https://apple.com/, NSErrorFailingURLKey=https://apple.com/, _kCFStreamErrorDomainKey=4} The DNS I'm using is 8.8.8.8. Do you know any other DNS server that supports DNSSEC? If I remove requiresDNSSECValidation from request it works. Also, it's curious that even failing the receiveCompletion is never called. But if I use the dataTask` with completion it's called with the error. Thanks for the clarifications.

Hi: Is there anyway to set a specific PrivacyContext to a concrete (no shared) URLSession? Thanks in advance

I am trying to connect to a socket using a url, which I can confirm connects successfully when using a socket connect tool, but when I try using URLSessionWebSocketTask it fails with the error: Note: have had to replace url domain and endpoint with *example.com/endpoint` for work reasons ... NSLocalizedDescription=A server with the specified hostname could not be found.} FAIL: Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found." UserInfo={NSErrorFailingURLStringKey=https://example.com/endpoint, NSLocalizedDescription=A server with the specified hostname could not be found., NSErrorFailingURLKey=https://example.com/endpoint} The url I provide starts with the wss prefix: let socketUrl = "wss://example.com/endpoint" ... webSocketTask = urlSession.webSocketTask(with: socketUrl) webSocketTask?.resume() but the error posted earlier indicates that the task is trying to connect using https instead (which the server does not support). I don't remember having to setup anything last time, but it has been about a year since working with these things. Have I missed something setup or app transport security settings etc?

Hi, My app transmits XML, images and video with IoT devices through HTTP requests. The local network is created through hotspot. Therefore, there is no domain name and static IP address in compile time. Is there any way to configure the ATS in runtime or allow HTTP requests in production?

Experiencing alot of crash in libcorecrypto.dylib. Also stack trace doesn't provide much information. So can we pls get a help on this? Stack trace: Crashed: com.apple.CFNetwork.Connection EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000051da5f80 Crashed: com.apple.CFNetwork.Connection 0 libcorecrypto.dylib 0x5bb30 ccmode_gcm_update_pad + 48 1 libcorecrypto.dylib 0x673c ccmode_gcm_set_iv + 356 2 libcorecrypto.dylib 0x5baac ccgcm_set_iv + 104 3 libboringssl.dylib 0x35ba4 aead_aes_gcm_seal_scatter + 220 4 libboringssl.dylib 0x29ca4 EVP_AEAD_CTX_seal_scatter + 296 5 libboringssl.dylib 0x84e94 bssl::SSLAEADContext::SealScatter(unsigned char*, unsigned char*, unsigned char*, unsigned char, unsigned short, unsigned char const*, bssl::Span, unsigned char const*, unsigned long, unsigned char const*, unsigned long) + 932 6 libboringssl.dylib 0x23404 bssl::do_seal_record(ssl_st*, unsigned char*, unsigned char*, unsigned char*, unsigned char, unsigned char const*, unsigned long) + 404 7 libboringssl.dylib 0x22f08 bssl::tls_seal_record(ssl_st*, unsigned char*, unsigned long*, unsigned long, unsigned char, unsigned char const*, unsigned long) + 312 8 libboringssl.dylib 0x4903c bssl::do_tls_write(ssl_st*, int, unsigned char const*, unsigned int) + 472 9 libboringssl.dylib 0x49500 bssl::tls_dispatch_alert(ssl_st*) + 116 10 libboringssl.dylib 0x5459c SSL_shutdown + 204 11 libboringssl.dylib 0x6730 boringssl_session_disconnect + 76 12 libboringssl.dylib 0xf8d8 nw_protocol_boringssl_disconnect + 96 13 Network 0x901b04 -[NWConcrete_nw_endpoint_flow cancelWithHandler:forced:] + 1304 14 Network 0x3fcc80 nw_endpoint_handler_cancel + 1068 15 Network 0x35969c __nw_connection_cancel_inner_block_invoke + 1208 16 Network 0x358f6c nw_connection_cancel_inner + 316 17 Network 0x358bb8 nw_connection_cancel + 116 18 CFNetwork 0x37080 CFURLRequestSetShouldStartSynchronously + 7304 19 CFNetwork 0xd5678 _CFURLCachePersistMemoryToDiskNow + 7212 20 CFNetwork 0xd5430 _CFURLCachePersistMemoryToDiskNow + 6628 21 libdispatch.dylib 0x2320 _dispatch_call_block_and_release + 32 22 libdispatch.dylib 0x3eac _dispatch_client_callout + 20 23 libdispatch.dylib 0xb534 _dispatch_lane_serial_drain + 668 24 libdispatch.dylib 0xc0d8 _dispatch_lane_invoke + 436 25 libdispatch.dylib 0xd394 _dispatch_workloop_invoke + 1764 26 libdispatch.dylib 0x16cdc _dispatch_workloop_worker_thread + 648 27 libsystem_pthread.dylib 0xddc _pthread_wqthread + 288 28 libsystem_pthread.dylib 0xb7c start_wqthread + 8 com.apple.main-thread 0 libsystem_kernel.dylib 0xc84 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x13b54 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x13e2c mach_msg_overwrite + 540 3 libsystem_kernel.dylib 0x11c8 mach_msg + 24 4 CoreFoundation 0x79114 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x7a340 __CFRunLoopRun + 1208 6 CoreFoundation 0x7f4dc CFRunLoopRunSpecific + 612 7 GraphicsServices 0x135c GSEventRunModal + 164 8 UIKitCore 0x39d37c -[UIApplication _run] + 888 9 UIKitCore 0x39cfe0 UIApplicationMain + 340 10 0x18b10 main + 17 (main.swift:17) 11 ??? 0x1dbca8dec (Missing)

Hi, after migrating app to Xcode 14.1, experiencing frequent CFNetwork crashes like the one below. Can you suggest any ideas on this? Thank you. Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Triggered by Thread: 13 Last Exception Backtrace: 0 CoreFoundation 0x1c0f1ce38 __exceptionPreprocess + 164 (NSException.m:202) 1 libobjc.A.dylib 0x1ba0a78d8 objc_exception_throw + 60 (objc-exception.mm:356) 2 CoreFoundation 0x1c109181c -[NSObject(NSObject) doesNotRecognizeSelector:] + 136 (NSObject.m:140) 3 CoreFoundation 0x1c0f32f50 ___forwarding___ + 1592 (NSForwarding.m:3578) 4 CoreFoundation 0x1c0f9b320 _CF_forwarding_prep_0 + 96 (:-1) 5 CFNetwork 0x1c20b451c HTTPHeaderDict::copyStringValue(__CFAllocator const*, HTTPHeaderKeyMixedValue const&) const + 100 (HTTPHeaderDict.cpp:131) 6 CFNetwork 0x1c20caef8 HTTPMessage::copyHeaderFieldValue(CFNetworkConstantString::HTTPHeader::DomainString) + 120 (HTTPMessage.cpp:108) 7 CFNetwork 0x1c224f0a4 HTTP2Stream::scheduleAndOpenWithHandler(CoreSchedulingSet const*, void (__CFHTTPMessage*, NSObject<OS_dispatch_data>*, CFStreamError const*) block_pointer, void (unsigned char) block_pointer) + 720 (HTTP2Stream.cpp:1750) 8 CFNetwork 0x1c222b7a0 HTTPProtocol::useNetStreamInfoForRequest(MetaNetStreamInfo*, HTTPRequestMessage const*, unsigned char) + 3568 (HTTPProtocol.cpp:2959) 9 CFNetwork 0x1c2211284 HTTP2ConnectionCacheEntry::enqueueRequestForProtocol(MetaConnectionCacheClient*, HTTPRequestMessage const*, MetaConnectionOptions) + 1172 (HTTP2ConnectionCacheEntry.cpp:186) 10 CFNetwork 0x1c22f9a44 HTTP2ConnectionCache::ingestTube(Tube*, bool) + 1472 (HTTP2ConnectionCacheEntry.cpp:279) 11 CFNetwork 0x1c20df004 TubeManager::newTubeReady(Tube*, CFStreamError) + 4956 (TubeManager.cpp:757) 12 CFNetwork 0x1c20f76c8 ___ZN11TubeManager22_onqueue_createNewTubeEP22HTTPConnectionCacheKey_block_invoke + 72 (TubeManager.cpp:473) 13 CFNetwork 0x1c20b55a0 Tube::_onqueue_invokeCB(CFStreamError) + 360 (Tube.cpp:1317) 14 CFNetwork 0x1c20bb864 NWIOConnection::_signalEstablished() + 540 (NWIOConnection.cpp:5912) 15 CFNetwork 0x1c21a84b8 ___ZN14NWIOConnection24_handleEvent_ReadyFinishEv_block_invoke + 712 (NWIOConnection.cpp:2662) 16 CFNetwork 0x1c2215ad4 ___ZN4Tube24postConnectConfigurationEPU28objcproto17OS_tcp_connection8NSObjectPU27objcproto16OS_nw_parametersS0_U13block_pointerFvvE_block_invoke + 832 (Tube.cpp:1751) 17 CFNetwork 0x1c213a89c BlockHolderVar<std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError>::invoke_normal(std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError) + 64 (AutoTypes.h:585) 18 CFNetwork 0x1c2298eb0 ProxyConnectionEstablishment::postProxyConnectionConfiguration(__CFAllocator const*, std::__1::shared_ptr<TransportConnection>, NSObject<OS_nw_parameters>*, __CFHTTPMessage*, HTTPConnectionCacheKey... + 652 (AutoTypes.h:576) 19 CFNetwork 0x1c22156d4 Tube::postConnectConfiguration(NSObject<OS_tcp_connection>*, NSObject<OS_nw_parameters>*, void () block_pointer) + 728 (Tube.cpp:1765) 20 CFNetwork 0x1c20b1dd8 ___ZN14NWIOConnection22_setupConnectionEventsEv_block_invoke + 2200 (NWIOConnection.cpp:2572) 21 libdispatch.dylib 0x1c8544114 _dispatch_block_async_invoke2 + 148 (queue.c:555) 22 libdispatch.dylib 0x1c8534f88 _dispatch_client_callout + 20 (object.m:560) 23 libdispatch.dylib 0x1c853c640 _dispatch_lane_serial_drain + 672 (inline_internal.h:2632) 24 libdispatch.dylib 0x1c853d1c0 _dispatch_lane_invoke + 436 (queue.c:3940) 25 libdispatch.dylib 0x1c853e4a4 _dispatch_workloop_invoke + 1780 (inline_internal.h:0) 26 libdispatch.dylib 0x1c8547e10 _dispatch_workloop_worker_thread + 652 (queue.c:6876) 27 libsystem_pthread.dylib 0x20f194df8 _pthread_wqthread + 288 (pthread.c:2618) 28 libsystem_pthread.dylib 0x20f194b98 start_wqthread + 8 (:-1)

Hi, after migrating app to Xcode 14.1, experiencing frequent CFNetwork crashes like the one below. Can you suggest any ideas on this? Thank you. Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001ba50301c Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [488] Triggered by Thread: 13 Thread 13 name: Thread 13 Crashed: 0 CoreFoundation 0x00000001ba50301c CFStringCreateCopy + 64 (CFInternal.h:982) 1 CFNetwork 0x00000001bb61d584 _merge_array_string(void const*, void const*, void*) + 92 (HTTPHeaderDict.cpp:131) 2 CoreFoundation 0x00000001ba4e2324 __CFDictionaryApplyFunction_block_invoke + 28 (CFDictionary.c:334) 3 CoreFoundation 0x00000001ba50a300 CFBasicHashApply + 148 (CFBasicHash.c:1037) 4 CoreFoundation 0x00000001ba50af30 CFDictionaryApplyFunction + 320 (CFDictionary.c:333) 5 CFNetwork 0x00000001bb675504 HTTPHeaderDict::copyAsOrdinaryDict(__CFAllocator const*) const + 92 (HTTPHeaderDict.cpp:183) 6 CFNetwork 0x00000001bb7c0470 HTTP2Stream::scheduleAndOpenWithHandler(CoreSchedulingSet const*, void (__CFHTTPMessage*, NSObject<OS_dispatch_data>*, CFStreamError const*) block_pointer, void (unsigned char) block_pointer) + 1468 (HTTP2Stream.cpp:571) 7 CFNetwork 0x00000001bb79c880 HTTPProtocol::useNetStreamInfoForRequest(MetaNetStreamInfo*, HTTPRequestMessage const*, unsigned char) + 3568 (HTTPProtocol.cpp:2959) 8 CFNetwork 0x00000001bb782364 HTTP2ConnectionCacheEntry::enqueueRequestForProtocol(MetaConnectionCacheClient*, HTTPRequestMessage const*, MetaConnectionOptions) + 1172 (HTTP2ConnectionCacheEntry.cpp:186) 9 CFNetwork 0x00000001bb86aacc HTTP2ConnectionCache::ingestTube(Tube*, bool) + 1472 (HTTP2ConnectionCacheEntry.cpp:279) 10 CFNetwork 0x00000001bb6500dc TubeManager::newTubeReady(Tube*, CFStreamError) + 4956 (TubeManager.cpp:757) 11 CFNetwork 0x00000001bb6687a0 ___ZN11TubeManager22_onqueue_createNewTubeEP22HTTPConnectionCacheKey_block_invoke + 72 (TubeManager.cpp:473) 12 CFNetwork 0x00000001bb626678 Tube::_onqueue_invokeCB(CFStreamError) + 360 (Tube.cpp:1317) 13 CFNetwork 0x00000001bb62c93c NWIOConnection::_signalEstablished() + 540 (NWIOConnection.cpp:5912) 14 CFNetwork 0x00000001bb719598 ___ZN14NWIOConnection24_handleEvent_ReadyFinishEv_block_invoke + 712 (NWIOConnection.cpp:2662) 15 CFNetwork 0x00000001bb786bb4 ___ZN4Tube24postConnectConfigurationEPU28objcproto17OS_tcp_connection8NSObjectPU27objcproto16OS_nw_parametersS0_U13block_pointerFvvE_block_invoke + 832 (Tube.cpp:1751) 16 CFNetwork 0x00000001bb6ab970 BlockHolderVar<std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError>::invoke_normal(std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError) + 64 (AutoTypes.h:585) 17 CFNetwork 0x00000001bb809f38 ProxyConnectionEstablishment::postProxyConnectionConfiguration(__CFAllocator const*, std::__1::shared_ptr<TransportConnection>, NSObject<OS_nw_parameters>*, __CFHTTPMessage*, HTTPConnectionCacheKey... + 652 (AutoTypes.h:576) 18 CFNetwork 0x00000001bb7867b4 Tube::postConnectConfiguration(NSObject<OS_tcp_connection>*, NSObject<OS_nw_parameters>*, void () block_pointer) + 728 (Tube.cpp:1765) 19 CFNetwork 0x00000001bb622eb0 ___ZN14NWIOConnection22_setupConnectionEventsEv_block_invoke + 2200 (NWIOConnection.cpp:2572) 20 libdispatch.dylib 0x00000001c1ab0114 _dispatch_block_async_invoke2 + 148 (queue.c:555) 21 libdispatch.dylib 0x00000001c1aa0fdc _dispatch_client_callout + 20 (object.m:560) 22 libdispatch.dylib 0x00000001c1aa8694 _dispatch_lane_serial_drain + 672 (inline_internal.h:2632) 23 libdispatch.dylib 0x00000001c1aa9214 _dispatch_lane_invoke + 436 (queue.c:3940) 24 libdispatch.dylib 0x00000001c1aaa4f8 _dispatch_workloop_invoke + 1780 (inline_internal.h:0) 25 libdispatch.dylib 0x00000001c1ab3e10 _dispatch_workloop_worker_thread + 652 (queue.c:6846) 26 libsystem_pthread.dylib 0x0000000208515df8 _pthread_wqthread + 288 (pthread.c:2618) 27 libsystem_pthread.dylib 0x0000000208515b98 start_wqthread + 8 (:-1)