Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimplement interception by using swizzling instead of URLProtocol #34

Open
akashivskyy opened this issue May 11, 2017 · 1 comment
Open

Comments

@akashivskyy
Copy link
Collaborator

akashivskyy commented May 11, 2017

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:

  1. 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.

  2. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

@akashivskyy akashivskyy added this to the 2.0 milestone May 11, 2017
@mmackowiak
Copy link

mmackowiak commented Jun 16, 2017

+1 for this one. Especially useful for 3rd party debugging, but also other traffic, not necessarily owned by app, like AVPlayer. FLEX debugger can be probably used as a reference, from what I've seen, swizzling is used there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants