Yep it totally make sense, just too bad it's not documented in the `[NSURLSession sharedSession]` documentation.

So in summary, you can change the behavior and `NSURLProtocol` classes between the various calls on `[NSURLSession sharedSession]` and the requests WILL be affected by those changes:

```
[[NSURLSession sharedSession] dataTaskWithURL:… completionHandler:…]; // 1
[NSURLProtocol registerClass:…]; // This NSURLProtocol class will be taken into account for the next dataTask below
[[NSURLSession sharedSession] dataTaskWithURL:… completionHandler:…]; // 2
[NSURLProtocol unregisterClass:…]; // The NSURLProtocol class will not be taken into account anomore for the next dataTask below
[[NSURLSession sharedSession] dataTaskWithURL:… completionHandler:…]; // 3 same as 1
```

That's handy and useful for sure, and an easy way to migrate fro `NSURLConnection` to `NSURLSession`, but should really be documented as this behavior for `sharedSession` is the opposite of the behavior described for other `NSURLSession` created using an `NSURLSessionConfiguration` whose behavior can't be changed once created!

---

So Apple should probably document this specific behavior of `[NSURLSession sharedSession]` better, for example like this instead [suggestion] :

> The shared session is based on the default configuration but uses the currently set global NSURLCache, NSHTTPCookieStorage, and NSURLCredentialStorage objects and the currently registered NSURLProtocol classes. Contrary to `NSURLSession` based on a `NSURLSessionConfiguration`, requests sent using the `sharedSession` uses settings for the `NSURLCache`, `NSHTTPCookieStorage`, `NSURLCredentialStorage` and `NSURLProtocol` classes that are interpreted at the time the requests are made (and not at the time the session is created)