fix issue where user specified interceptors where being overridden b…

[raghucha]

Use the user Provided Interceptor as higher preference in the Interceptor chain

Fixes #bug 1757

Changes proposed in this pull request

• Currently there is no way to override the default Interceptors behaviour, This pull request take the user provided interceptor with more precedence

Other links

[Ndiritu]

Thanks for the changes @raghucha. We might have a bigger problem here.

I think this could lead to conflicts since the order of handlers in the pipeline matters. e.g. by default all retries/redirects should include query parameter name decoding etc. A potential customization of query parameter decoding could mean it's added before the retry & redirect handlers..

I think we should avoid filling in missing middleware totally in case a developer chooses to pass their own interceptors. This seems to align with .NET and other languages as well.

Thoughts @baywet @andrueastman?

[baywet]

correct, order matters, and this change might impact it. This is what was done in dotnet to address the same concern. We should probably align with that instead.
microsoft/kiota-http-dotnet#246

[Ndiritu]

Thanks for added context Vincent. Would you like to implement this instead @raghucha?

[raghucha]

i can implement it however i have few design question . Below is a sample code from KiotaClientFactory. If anyone uses below method to create a Client they will never be able to Override the default interceptor functionality .And Question such as if they use addInterceptor Method will also never be able to override . Is this acceptable?

@Nonnull public static OkHttpClient.Builder create(
           @Nonnull final BaseBearerTokenAuthenticationProvider authenticationProvider) {
       ArrayList<Interceptor> interceptors = new ArrayList<>(createDefaultInterceptorsAsList());
       interceptors.add(new AuthorizationHandler(authenticationProvider));
       return create(interceptors);
   }

[baywet]

The createDefaultInterceptorsAsList was added two days ago. I'm not sure why we made it public @Ndiritu ?
If that was an oversight, I'd be ok with making it private again.

Regardless of whether we keep it public, we should be able to add overloads all the way down the stack that accept options. And simply point the current methods that do not accept the options to call those new overloads.

Let us know if you have any additional comments or questions.

[Ndiritu]

Apologies, I should have made this clearer in the PR description.

[baywet]

are we using it outside of kiota java? (i.e. here in core)

[Ndiritu]

Added a similar create(List<Interceptor>) overload in Graph core ref but not createDefaultInterceptorsAsList(). The latter is only in Kiota Java.

[raghucha]

am i correct in assuming even with the fix in KiotaClientFactory as done in .net we would not be able to overload the default interceptor using . addInterceptor method, we a need to pass it as constructor of the create method ( as there is no option to remove an interceptor once its added?)

[Ndiritu]

am i correct in assuming even with the fix in KiotaClientFactory as done in .net we would not be able to overload the default interceptor using . addInterceptor method, we a need to pass it as constructor of the create method ( as there is no option to remove an interceptor once its added?)

Yes, addInterceptor() won't overload. It's a built-in OkHttp method to append interceptors

[Edit]
Link to OkHttp implementation

[Ndiritu]

Worked on the changes here - #1795