>I am wondering, does this protocolClasses property of NSURLSessionConfiguration means that +[NSURLProtocol registerClass] only has effects on requests sent via NSURLConnection

That seems to be the case, yes. As far as I understand it, `NSURLSession` is designed to be a session "container" of sorts for managing all network traffic sent through it, therefore it is designed such that no globally shared networking mechanisms affect a particular session instance (except the default session). I don't see this as a bad thing, though - it's really powerful for managing discrete networking sessions, say for a particular API or set of API routes out of several with which an app is communicating.

However, `registerClass:` **does** work with `[NSURLSession sharedSession]`, so it makes sense that the shared session is designed to stand-in for the previous global usage of `NSURLConnection`. I added a test for the shared session to my pull request branch. Because of this, I don't think it's necessary to do any swizzling - the stubbing will still work for people who just want to use the shared session. However, for AFNetworking, the shared session is never used, so the enabling per-configuration is still necessary.

> What if some NSURLProtocol subclass is listed in -[NSURLSessionConfiguration protocolClasses] array but was not registered using [NSURLProtocol registerClass:]? Does it still get used by NSURLSession because listed in protocolClasses, even if not registered?

As far as I can tell, yes - that is the new mechanism for registering a protocol. I commented out `registerClass` in `OHHTTPStubs` and it still works.