You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 URLProtocol requires 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 multiple URLSessions.
Using URLProtocol that internally uses another URLSession prevents users of ResponseDetective from using their custom URLSession subclasses or even URLSessionDelegates. Since URLProtocol doesn'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 URLSession instance. This makes them more configurable and even more testable. This resolves the first problem of URLProtocol.
Since the trampoline of URLSessionDelegate would bounce back to the "original" delegate set by user, users will still be able to customize the behavior of URLSession directly (even by subclassing it). This resolves the second problem of URLProtocol and Does not work with skipped certificate validation #2.
Swizzling doesn't require users to pass custom URLSessionConfigurations to URLSessions during initialization, which enables them to inject ResponseDetective at any time to any existing instance of URLSession.
Swizzling can optionally be done globally during application launch, which would enable users to inject ResponseDetective to URLSession instances 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.
Using a custom
URLProtocolsubclass 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
URLProtocolis to use swizzling to create a trampoline ofURLSessionDelegatethat 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.