How to handle HTTP 307/308/301 with Authorization header?

[jvmlet]

This is basically same as #869 , when server returns 307/308/301, the Authorization header is not re-sent.
I'm on latest 23.4.2
My config :

{
"Routes": [
 {
      "UpstreamPathTemplate": "/blah/{everything}",
      "UpstreamHttpMethod": [
        "HEAD",
        "GET",
        "POST",
        "PUT",
        "DELETE",
        "OPTIONS"
      ],
      "DownstreamPathTemplate": "/{everything}",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 80
        }
      ],
      "RouteIsCaseSensitive": false,
      "DangerousAcceptAnyServerCertificateValidator": true,
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "Bearer",
        "AllowedScopes": []
      },
      "RateLimitOptions": {
        "EnableRateLimiting": true,
        "Period": "30s",
        "PeriodTimespan": 10,
        "Limit": 300
      },
      "QoSOptions": {
        "ExceptionsAllowedBeforeBreaking": 10,
        "DurationOfBreak": 30000,
        "TimeoutValue": 60000
      },
      "HttpHandlerOptions": {
        "AllowAutoRedirect": true,
        "UseCookieContainer": true,
        "UseTracing": true,
        "MaxConnectionsPerServer": 300
      }
    },
]
}

[raman-m]

Hello, Alexander.
Do you confirm that this your issue is duplicate of #869 and the steps to repro are the same?
If Not, please describe the difference.

[jvmlet]

Yes, exactly the same

[raman-m]

Do you have a solution in mind, and will you open a pull request soon to fix this?
What do you propose?

[jvmlet]

Sorry, but no.
My solution was basically a workaround ... get rid of redirect and implement internal forward (url rewrite).
Cost me few hours to figure out the strange behavior when direct requests (from browser) work, but proxied - not :-(.

[raman-m]

My solution was basically a workaround ... get rid of redirect and implement internal forward (url rewrite).

It appears that you are developing downstream services; therefore, customization of Ocelot app is not necessary.

Cost me few hours to figure out the strange behavior when direct requests (from browser) work, but proxied - not :-(.

As far as I understand you, direct consumption of the service is working, but when proxying requests through Ocelot app, it breaks the workflow, right? Have you identified what exact HTTP request artifacts were missing that led to the broken workflow? Headers?

[raman-m]

I recommended you to define anonymous route, without authentication, and forward everything to downstream service without any custom logic on Ocelot's side.

[jvmlet]

Thanks. but as i already said, I overcame this limitation by eliminating redirect.
Still, such a mature product as Ocelot, should support headers propagation between redirects OOTB...

[raman-m]

Please, remember forever that HTTP protocol is stateless!

[raman-m]

Thanks. but as i already said, I overcame this limitation by eliminating redirect.

But you can't eliminate this redirection because of downstream service behavior... Do you develop downstream service or simply consume it?
Are you certain there are limitations in Ocelot, really?

What are the response headers of the initial response with a 307 status?
What is the value of the Location header for a 307 status?
What occurs in the browser or API tool when initial request is made without Ocelot routing?
What is the standard authentication workflow to the downstream service?

[raman-m]

My solution was basically a workaround ... get rid of redirect and implement internal forward (url rewrite).

I can't get you!... Do you develop downstream service or consume it?

[raman-m]

Still, such a mature product as Ocelot, should support headers propagation between redirects OOTB...

In your opinion, what constitutes mature products? Browsers? And do you expect standard browser's behavior in Ocelot, right?

Allow me to explain the recognized standard for the 307 status 👇

Quotes from 307 status

A browser receiving this status will automatically request the resource at the URL in the Location header, redirecting the user to the new page. Search engines receiving this response will not attribute links to the original URL to the new resource, meaning no SEO value is transferred to the new URL.

Ocelot is not a browser; it merely forwards incoming requests. Ocelot has no custom decision logic, and it should not. Its behavior is based on standards of the HTTP protocol (statuses) and the implemented .NET framework (the SocketsHttpHandler class).

The method and the body of the original request are reused to perform the redirected request. In the cases where you want the request method to be changed to GET, use 303 See Other instead. This is useful when you want to give an answer to a successful PUT request that is not the uploaded resource, but a status monitor or confirmation message like "You have successfully uploaded XYZ".

It appears that the reuse of the same HTTP method and body should be a standard behavior of SocketsHttpHandler when the user has enabled the AllowAutoRedirect property.

Could you provide concrete proof that this and status 307 behavior is malfunctioning in Ocelot?

[raman-m]

Ocelot Architecture of HTTP Redirects

As mentioned in Ocelot Configuration doc users can enable/disable the AllowAutoRedirect property:

• Follow Redirects also known as HttpHandlerOptions

If you search for the AllowAutoRedirect property, it will show the rare processing of the property:

1. The property configuration code in Ocelot Core:
   

   Ocelot/src/Ocelot/Configuration/Creator/HttpHandlerOptionsCreator.cs

   Line 27 in d1ecfaf

   return new HttpHandlerOptions(options.AllowAutoRedirect,

2. The property initialization inside SocketsHttpHandler object (Ocelot Core constructs request to downstream)
   

   Ocelot/src/Ocelot/Requester/MessageInvokerPool.cs

   Line 75 in d1ecfaf

   AllowAutoRedirect = downstreamRoute.HttpHandlerOptions.AllowAutoRedirect,

This logic is quite clean (no decision logic at all). However, we might encounter bottlenecks in the response headers logic, so we need to double-check the actual headers the client receives 👉

Ocelot/src/Ocelot/Middleware/DownstreamResponse.cs

Line 33 in d1ecfaf

public List<Header> Headers { get; }

[raman-m]

About Authorization header

Let's read these Remarks carefully 👉

• SocketsHttpHandler.AllowAutoRedirect Property | Remarks

The quote:

The Authorization header is cleared on auto-redirects and the handler automatically tries to re-authenticate to the redirected location. No other headers are cleared. In practice, this means that an application can't put custom authentication information into the Authorization header if it is possible to encounter redirection. Instead, the application must implement and register a custom authentication module.

Do you understand now?
And please tell me, Alexander, why on earth Ocelot should retain the Authorization header from the previous request if the enabled AllowAutoRedirect property delegates responsibility to SocketsHttpHandler which reuses the method and body, reads the Location header of 307 status, and it simply requests the new URL from the header?

[jvmlet]

Reading carefully, I note this:

the application must implement and register a custom authentication module.

How does Ocelot support the custom authentication module (DelegateHandler I suppose) in case AllowAutoRedirect is set to true ?
I see 2 options:

1. Add another config property to PropagateAuthorizationHeaderOnAutoRedirect
2. Provide special callback that is invoked on AutoRedirect while passing original HttpRequest to allow application to copy needed headers.

Please tell me, witch one Ocelot implements, and if not, what was the design to support Authorization when following redirects?

[raman-m]

Before everything, an alternative solution could be Handling 302 Redirects:

• Headers Transformation | Handling 302 Redirects

In this solution you have to switch off auto-redirects → "AllowAutoRedirect": false,. After that substitute Location header values correctly.
But if you want to develop a solution with auto-redirects aka "AllowAutoRedirect": true, then see my answers below.

[raman-m]

How does Ocelot support the custom authentication module (DelegateHandler I suppose) in case AllowAutoRedirect is set to true?

As I've already explained you, if auto-redirects is enabled in route configuration then Ocelot delegates behavior to SocketsHttpHandler when the user has enabled the AllowAutoRedirect property.
And Ocelot has no custom auth Delegating Handlers in its pipeline, because Ocelot's "authentication module" is AuthenticationMiddleware which reads Authorization header implicitly based on app startup code and auth provider setup.

I see 2 options:
1 Add another config property to PropagateAuthorizationHeaderOnAutoRedirect

It could be a new Ocelot feature but who will develop and deliver it?
I assume this new property in route configuration will be utilized by you only. Unfortunately, we will not incorporate any new configuration options in route JSON for infrequent scenarios. However, you are permitted to add a custom route property as Route Metadata and read the property in custom C# classes, following C# development in your forked repository, as our Dev Process allows.

2 Provide special callback that is invoked on AutoRedirect while passing original HttpRequest to allow application to copy needed headers.

This "callback" should be a custom developed Delegating Handler which must implement all the logic.

Please tell me, witch one Ocelot implements, and if not, what was the design to support Authorization when following redirects?

The AuthenticationMiddleware reads Authorization header implicitly when calling the AuthenticateAsync method.

Once again, if in route config "AllowAutoRedirect": true then Ocelot delegates behavior to SocketsHttpHandler when the user has enabled the AllowAutoRedirect property. Please note, SocketsHttpHandler does not add the Authorization header for the new request because it simply follows URL from Location header; and this is standard ASP.NET behavior!

Finally, we recommend developing custom Delegating Handler with all the logic inside to mimic browser behavior.

P.S.

In theory, your workflows should not be broken if the "AllowAutoRedirect": false when proxying HTTP requests by Ocelot. Could you confirm, please, that your web app (browser app) behaves correctly without auto-redirects?

[jvmlet]

Assume, I'm implementing option 2 :

1. Do I get the original request in my delegate to copy headers from ?
2. Can I distinguish requests ? I'm interested to propagate original Authorization header only for redirects.
   Thanks

[raman-m]

Case 1: AllowAutoRedirect is true

You require a custom "auto-redirects" feature that is not currently implemented in Ocelot. I noticed that you are a Java developer, may not have experience with C# code, making it difficult for you to develop a Delegating Handler module and integrate it into the Ocelot pipeline.
If you need professional consultation, please send an email to [email protected] with reference to this discussion.

Case 2: AllowAutoRedirect is false

Let's clear it up once again!

Can I distinguish requests? I'm interested to propagate original Authorization header only for redirects. Thanks

1. Disable any authentication entirely: make the route anonymous by removing AuthenticationOptions from the route JSON.
2. Then, the browser (or another client) initiates the 1st request with the desired Authorization header. Add the header to the 1st request on the client's side. Since the route is anonymous, your client should recognize a 3xx status.
3. After that, create a 2nd request with the URL from the Location header of the 1st response, add the Authorization header, and make the request again. Ensure it is properly proxied by Ocelot.
4. Finally, your 2nd response should have a successful 2xx status.

Note that in this Case 2 scenario, you (your HTTP client) are/is responsible for header propagation, because you are consumer of downstream service, and know the API usage!

[jvmlet]

Thank you very much for your professional support, no more questions left.