RequestDL
Replies: 1 comment
-
Revised ProposalDuring the review of URLSession support on the Darwin platform, we found that SwiftNIO + AsyncHTTPClient is better suited for server-side application contexts and low-level communication where granular control of protocols and certificates is necessary. AsyncHTTPClient offers a wide range of customizations for TLS, HTTP, schemes, certificates, and methods for validating the server and even the client. Moreover, all network layer cryptography is handled by BoringSSL, an open-source framework. This flexibility provided by AsyncHTTPClient is also matched by SwiftNIO, which impresses with its ability to rewrite the network layer and provide a high level of customization (compared to URLSession). However, URLSession implemented by the Foundation framework also has its own strengths that should not be underestimated. In the Apple app ecosystem distributed via the App Store, there are various layers of security and encryption standards provided by Apple through macOS, iOS, tvOS, watchOS, and visionOS. The network layer of the Darwin platform consists of three major frameworks: Foundation, Network, and Security. They all have unique integrations with the system that SwiftNIO cannot provide due to its generalized support for different platforms. Although SwiftNIO is open and uses BoringSSL, URLSession is secure and uses Security to efficiently handle SSL, TLS, and other communication aspects within the Apple platform. RequestDL has evolved significantly with the features provided by AsyncHTTPClient but has become primarily a framework for server applications and low-level internet communication. Integrating URLSession would only be possible by rewriting many internal structures. Some features would simply not be available, and others would appear exclusively for Darwin. Various solutions to this problem were analyzed and tested, but all failed in parts. The possibility of RequestDL providing hybrid support for SwiftNIO + URLSession is extremely complex and subject to a series of failures. Therefore, we have concluded to branch RequestDL into two repositories. As part of an incremental change, we will be providing Repository Structure
Open API Support
LabelsWe'll add three new labels to keep issues, discussion and other GitHub contents to maintain everything related to each repository. The |
Beta Was this translation helpful? Give feedback.
-
The #185 is being reviewed to collect all informations needed to implement this.
Goals
While we are uncertain whether this solution will be successful or if it will address all our concerns, we want to ensure thorough documentation of our approach. Here are some initial considerations:
Develop a logic within RequestDL to determine whether URLSession or AsyncHTTPClient should be used.
This flag should be set to
truewhen it is feasible to execute the specified request using URLSession.Integrate Streams with URLSessionDelegate.
At first glance, it appears that we can utilize the same async response steps in URLSession, but further investigation is required.
Leverage RequestTask contexts.
Since we already have
UploadTask,DownloadTask, andDataTask, we can potentially align them with URLSession'supload,download, andtaskto take advantage of the URLSession API's conventions.Adapt SecureConnection to Security or URLSessionDelegate methods.
We need to explore the possibilities enabled by URLSession within the RequestDL codebase.
DefaultTrusts,Trusts, andAdditionalTrust)CertificatesandPrivateKey)PSKIdentity)Implementation
If the planning phase progresses smoothly, we believe that we can implement these changes incrementally in small contributions to RequestDL. Each contribution will be released as a separate version.
Beta Was this translation helpful? Give feedback.
All reactions