-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ocelot returning 307 instead of rerouting the request #779
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 |
Redirect and the browser then sends the raw request directly to the endpoint. In the target service i have commented .UseHttpsRedirection(), but not working still. Thanks. |
When u set {
"DownstreamPathTemplate": "/api/{everything}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 5001
}
],
"UpstreamPathTemplate": "/mobile/api/{everything}",
"UpstreamHttpMethod": []
} I work with it! |
Dear @Kaffeekaethe ! Regarding redirects via Configuration... "HttpHandlerOptions": {
"AllowAutoRedirect": true,
"UseCookieContainer": true,
"UseTracing": true,
"MaxConnectionsPerServer": 100
}, |
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:
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.
The text was updated successfully, but these errors were encountered: