Ocelot returning 307 instead of rerouting the request

Created on 6 Feb 2019  路  1Comment  路  Source: ThreeMammals/Ocelot

Prerequisites / Expected Behavior

Running a frontend based on VueJS / TypeScript in Chrome and sending a GET-Request with an Authentication header set to a token. Thus, Chromse sends an OPTIONS-Request, retaining that the Authentication header is allowed, and then sends the GET-Request. I except that GET-Request to be forwarded the same way.

Actual Behavior

Instead of rerouting the Request to the backend service, Ocelot replies to the GET-Request with 307 Redirect and the browser then sends the raw request directly to the endpoint, not using the middleware.

Additional configuration-info:

Ocelot has injected an AuthenticationMiddleware that validates the token and adds custom headers for the backend service, giving it more detailed information which user is mapped to the token. To achieve this, we have tried two things:

1) Injecting with

    var configuration = new OcelotPipelineConfiguration
            {
                AuthenticationMiddleware = async (context, next) =>
                {
                    await AuthorizeAsync(context, next);
                }
            };

2) Adding a Global Handler:

services.AddOcelot(Configuration).AddDelegatingHandler<AuthHandler>(true);

In both solutions we add the header to the _DownstreamRequest_. The path is correctly mapped to the Downstream-Service. In both cases the DownStream-Service gets only half of the requests, the other half get Statuscode 307.

There is no additional configuration.

This only happens in the browser and not when using another tool like Postman, however I still suspect that has to happen somewhere when Ocelot sets the Statuscode for the Response.

I looked at the repository but was not able to find anything that gives me hint on to what I am doing wrong.

Most helpful comment

Hi

Just in case, this is still relevant to you (or somebody else).

I had the same problem. It was caused by the target micro-service where the .UseHttpsRedirection() was enabled. So the request ended up at the correct target service but was redirected there from http to https.

Cheers, Mike

>All comments

Hi

Just in case, this is still relevant to you (or somebody else).

I had the same problem. It was caused by the target micro-service where the .UseHttpsRedirection() was enabled. So the request ended up at the correct target service but was redirected there from http to https.

Cheers, Mike

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FerAguilarR93 picture FerAguilarR93  路  6Comments

yangzhongke picture yangzhongke  路  6Comments

bremnes picture bremnes  路  3Comments

ioritzalberdi picture ioritzalberdi  路  5Comments

FerAguilarR93 picture FerAguilarR93  路  3Comments