#9108 made it possible for Interceptors to access various OkHttpClient options from Interceptor.Chain.
However, it is not possible to access OkHttpClient.interceptors nor OkHttpClient.networkInterceptors in this way, as there are no accessors for them.
This presents a problem when implementing "transport" interceptors that wish to take over the Call and run it themselves (as opposed to passing it down OkHttp's stack), which is what we are trying to do. These interceptors never call chain.proceed(), but they may still want to access the list of interceptors for at least the following reasons:
- Configuration checking, e.g. warning that subsequent interceptors will not be run (to prevent user error);
- "Manually" running the remaining interceptors: this is especially relevant for network interceptors, which would not be run otherwise
We think a good solution would be to add interceptors and networkInterceptors fields to Interceptor.Chain, similar to the other accessors that were added in #9108.
One open question is whether these fields should return the entire list of interceptors, even those that have already run, or only those that remain to be run. I personally think the latter would make a bit more sense, but would be fine with the former.
A natural extension of this idea would be to also add withInterceptors() and withNetworkInterceptors() which would make it possible for an interceptor to dynamically change the list of interceptors that come after it. To be clear we do not need this, and are fine with this being left out of scope of this FR.
@yschimke @vkasprov
#9108 made it possible for Interceptors to access various OkHttpClient options from
Interceptor.Chain.However, it is not possible to access
OkHttpClient.interceptorsnorOkHttpClient.networkInterceptorsin this way, as there are no accessors for them.This presents a problem when implementing "transport" interceptors that wish to take over the Call and run it themselves (as opposed to passing it down OkHttp's stack), which is what we are trying to do. These interceptors never call
chain.proceed(), but they may still want to access the list of interceptors for at least the following reasons:We think a good solution would be to add
interceptorsandnetworkInterceptorsfields toInterceptor.Chain, similar to the other accessors that were added in #9108.One open question is whether these fields should return the entire list of interceptors, even those that have already run, or only those that remain to be run. I personally think the latter would make a bit more sense, but would be fine with the former.
A natural extension of this idea would be to also add
withInterceptors()andwithNetworkInterceptors()which would make it possible for an interceptor to dynamically change the list of interceptors that come after it. To be clear we do not need this, and are fine with this being left out of scope of this FR.@yschimke @vkasprov