-
Notifications
You must be signed in to change notification settings - Fork 91
Description
Using a custom URLProtocol subclass to intercept HTTP(S) traffic surely results in being a good citizen, but, as a way to debug apps, it comes with disadvantages:
-
First of all, the architecture of
URLProtocolrequires the subclasses to operate on static levels, essentially making them singletons. This has an implication that only one interception mechanism can exist at a time, even when using multipleURLSessions. -
Using
URLProtocolthat internally uses anotherURLSessionprevents users of ResponseDetective from using their customURLSessionsubclasses or evenURLSessionDelegates. SinceURLProtocoldoesn't have access to the custom delegates, issues line Does not work with skipped certificate validation #2 emerge.
The alternative to using a custom URLProtocol is to use swizzling to create a trampoline of URLSessionDelegate that would have the following advantages:
-
There can be multiple instances of interceptors, one per each
URLSessioninstance. This makes them more configurable and even more testable. This resolves the first problem ofURLProtocol. -
Since the trampoline of
URLSessionDelegatewould bounce back to the "original" delegate set by user, users will still be able to customize the behavior ofURLSessiondirectly (even by subclassing it). This resolves the second problem ofURLProtocoland Does not work with skipped certificate validation #2. -
Swizzling doesn't require users to pass custom
URLSessionConfigurations toURLSessions during initialization, which enables them to inject ResponseDetective at any time to any existing instance ofURLSession. -
Swizzling can optionally be done globally during application launch, which would enable users to inject ResponseDetective to
URLSessioninstances they do not own. This would enable them to debug traffic in third-party dependencies.
As seen above, using swizzling may eventually be a better, more customizable and safer implementation of ResponseDetective.