"POST" requests actually issuing GET

[mcoombe]

I have checked the following:

• I have searched existing issues and found nothing related to my issue.

This bug is:

• making Bruno unusable for me
• slowing me down but I'm able to continue working
• annoying
• this feature was working in a previous version but is broken in the current release.

Bruno version

2.10.0

Operating System

Ubuntu 22.04.5

Describe the bug

I'm in the process of building a Bruno collection for demonstrating a number of proprietary REST APIs, and have run into issues where some (but not all) of the POST requests defined in the collection are actually issuing GET requests when executed.

Specifically, in these particular cases:

• The Bruno UI indicates that the request is a POST on the request tab, and in the collection tree.
• Manual examination of the corresponding .bru file confirms the request is defined as a POST.
• When executing the request, the method is recorded as POST in the network log.
• Despite this, the server logs indicate a GET request was received, and the response is as would be expected for a GET request to the same API path.

Of about 40 requests defined in the collection, only two exhibit this behaviour (both POST requests). That's sufficient though that the collection is not suitable for the intended purpose, unfortunately.

.bru file to reproduce the bug

meta {
  name: Create data pool
  type: http
  seq: 6
}

post {
  url: {{ALETHEIA_API_URL}}/datapools
  body: json
  auth: inherit
}

body:json {
  {
    "id": "{{TEST_DATA_POOL_ID}}",
    "organisationId": "{{SANDBOX_ID}}",
    "name": "My Test Data Pool",
    "description": "A test data pool in my sandbox"
  }
}

settings {
  encodeUrl: true
}

Screenshots/Live demo link

UI elements describing the request as a POST highlighted in red. Despite this, the response displayed here contains a list of resources, as would be expected in response to a GET response to the same URL path. Server logs confirm the request was indeed a GET, not POST.

[Ansh2004P]

hi, I would like to work on this bug,

[anusree-bruno]

@mcoombe
Would it be possible to share the timeline?
Also can you confirm using curl that these POST requests are not getting redirected to a get request?

[anusree-bruno]

hi, I would like to work on this bug,

@Ansh2004P Where you able to reproduce on your end?

[Ansh2004P]

Hi @anusree-bruno, I tried to reproduce the bug but I found the issue was solved ig. It was working just fine with me

[LocTr]

I encountered the same issue. The server logs indicate a GET request, even though I tried sending requests with different methods such as POST, DELETE, etc. I verified the request with another client to confirm that the issue is with Bruno.

Environment

OS: Windows 11 24H2

Bruno version: 2.10.0

[anusree-bruno]

@LocTr Can you check on brunos network logs and see what is happening?

[LocTr]

@anusree-bruno I’ve figured it out. The issue was that the path contained // instead of /. The redundant slash was automatically removed, and the request fell back to GET. This was an error on my side, but the behavior is a bit confusing. Is this the intended behavior?

[mcoombe]

Based on the observation from @LocTr, I've discovered the source of the issue in my case: the ALETHEIA_API_URL variable interpolated into the POST request's URL was missing the scheme portion of the URL. That is, the URL being used in the request consisted of the hostname and path only, e.g. www.example.com/api/aletheia/datapools (missing the leading https://). It seems Bruno automatically prepended an http:// in this case, which resulted in the server returning a 301 to redirect to the HTTPS endpoint. This resulted in the same 301 fallback behaviour observed above.

While this was definitely an error on my part, I feel that the fallback behaviour observed here is highly confusing. If I configure a POST request, I don't expect it to be "magically" converted to a different request method. I can now fix my particular issue, but I still feel this fallback behaviour is a bug that should be corrected, or at the very least documented.

Update: Per section 10.3.2 of RFC 2616, this behaviour of changing POST to GET on a 301 response is explicitly called out as being erroneous. The RFC indicates that clients MUST NOT automatically redirect the request if the request method was anything other than GET or HEAD (as is the case here).