Requests follow redirects but don't indicate this in the timeline

[damirarh]

I have checked the following:

• I use the newest version of bruno.
• I've searched existing issues and found nothing related to my issue.

Describe the bug

I have a service which automatically redirects and HTTP requests to corresponding HTTPS URLs with a 307 response. When sending an HTTP request to such a service from Bruno, it automatically repeats the request to the HTTPS URL from the redirect response. However, the timeline view doesn't indicate this and makes it appear as if the final HTTPS response came from the original HTTP endpoint.

This gets even more confusing if such endpoints require a valid Authorization header. In this case, Bruno only sends the Authorization header to the HTTP endpoint, which results in a 307 response, but omits it from the second request to the HTTPS redirect URL, which therefore results in a 401 response.

The actual network communication is (including only relevant headers:

GET http://localhost:5194/weatherforecast/
Authorization: Bearer ...

HTTP/1.1 307
Location: https://localhost:7071/weatherforecast/

GET https://localhost:7071/weatherforecast/

HTTP/1.1 401
www-authenticate: Bearer

The timeline view in Bruno gives no indication of the redirect:

> GET http://localhost:5194/weatherforecast/
> Authorization: Bearer ...
< 401 Unauthorized
< content-length: 0
< date: Sat, 29 Jun 2024 15:59:50 GMT
< server: Kestrel
< www-authenticate: Bearer

Postmen behaves differently:

• it clearly shows both requests in its console view
• it includes the Authorization header in the second request which therefore succeeds

I think that Bruno should at least show details about both requests that were made.

.bru file to reproduce the bug

meta {
  name: Get via HTTP
  type: http
  seq: 2
}

get {
  url: http://localhost:5194/weatherforecast/
  body: none
  auth: bearer
}

auth:bearer {
  token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2xvY2FsaG9zdDo1MDAwIiwiYXVkIjoid2ViLWFwaS1vYXV0aC10ZXN0Iiwic3ViIjoidGVzdCIsImV4cCI6NDg3NTI0NjA1M30.NXEfjbeDtXtJ7v1rzzvZJIhc03zrTlrDFRcqy42-93oD5h03zhAcXnUE-g2qxoZOkrNqvr0xKqdD-ePKDisX0M8jJhvtccNmEZ88b9PJWljnp0dAu5kTWvstmnz-pxbji5JUy15wccoCJGAmUF4saybg1sh-cAFjaAf8ySV_nPP_9DdMPB31lHjOy6gwAwAEnHoJ_13RhIbmmq8wrAHSf3whkluKuRaHjqm2BgcP-SBfAykRTfMam8Xze3uHOLhgTps9AlIL3RyyvwXd7EFlBawEXDgJqMdONUsVdB5470VpahgiHi0u_f914XS3HDfrzm-sq4heqUyxcGMXchVAPQ
}

Screenshots/Live demo link

I have a GitHub repository containing (among other files):

• a .NET 8 project implementing the described redirect behavior
• a Bruno collection folder with the problematic HTTP request

To reproduce the behavior, you can run the project with the following command (assuming you have .NET 8 SDK installed):

cd WebApiOAuth
dotnet run -lp https

Once it's running, you can send the "Get via HTTP" request from Bruno to see the described behavior. The running .NET application will log requests and response to the console.

[Its-treason]

Checkout my fork: https://github.com/Its-treason/bruno/releases/tag/nightly It has this feature implemented with the "New request method".