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
We should probably have a way to attach a block to a request that can be used to customize the final URLRequest immediately prior to handing it to URLSession. This would primarily be used for allowing clients to use new URLSession features before PMHTTP has implemented them.
This should be configurable per-request, but also have a global default. A few alternatives for the global default, not sure yet which way is best:
A block that's used as the default for all requests, but is overridden per-request.
A block that is used as the default for all requests, in addition to the per-request block. The global block would run first, then the per-request block.
A block that is used as the default for environmental requests, but is overridden per-request.
I'm tempted to go with option 2, so that way the global block can also be used to implement other features, such as tracking every single time we send a network request. If we pass the HTTPManager and HTTPManagerRequest objects to the block as well then the block can manually implement the other behaviors (e.g. by bailing if there's a per-request block, or bailing if the URL doesn't belong to the environment).
We could also go ahead and implement all 3 behaviors and have it be configurable, though I'd rather not do this.
If the request is retried, this block would also run on each retry.
The text was updated successfully, but these errors were encountered:
We should probably have a way to attach a block to a request that can be used to customize the final
URLRequest
immediately prior to handing it toURLSession
. This would primarily be used for allowing clients to use newURLSession
features beforePMHTTP
has implemented them.This should be configurable per-request, but also have a global default. A few alternatives for the global default, not sure yet which way is best:
I'm tempted to go with option 2, so that way the global block can also be used to implement other features, such as tracking every single time we send a network request. If we pass the
HTTPManager
andHTTPManagerRequest
objects to the block as well then the block can manually implement the other behaviors (e.g. by bailing if there's a per-request block, or bailing if the URL doesn't belong to the environment).We could also go ahead and implement all 3 behaviors and have it be configurable, though I'd rather not do this.
If the request is retried, this block would also run on each retry.
The text was updated successfully, but these errors were encountered: