Skip to content
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

Curl for Http Calls #2165

Open
1 task done
helloanoop opened this issue Apr 25, 2024 · 2 comments
Open
1 task done

Curl for Http Calls #2165

helloanoop opened this issue Apr 25, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@helloanoop
Copy link
Contributor

I have checked the following:

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

Describe the feature you want to add

Overview

Today Bruno uses axios underneath to make http calls. We are seeing some issues where people say that it works perfectly in Insomnia but not working on Bruno.

This ticket is to explore options around providing curl as an option

Bruno will default to axios for making http request, The idea here is to provide a toggle in preferences to use curl instead of axios

Mockups or Images of the feature

TBD

@mjhcorporate
Copy link
Contributor

mjhcorporate commented Apr 27, 2024

I would argue to switch to curl completely. Supporting two backends creates extra work, and during support-requests we have to ask "which backend did you use?".

My reason: There is lots of subtle magic that axios applies, e.g. in the json-handling. Here I am sending an intentionally unusual json request, which I do to evaluate a certain class of security vulnerabilities on the servers I work with. For now, I am sending it to a simple echo server:


image

Here it looks like the echo server swallowed the first property. However, when I inspect console output of the echo-server (which prints the raw request string), I notice that only the first key was sent! Also, confusingly, Bruno (axios) stripped away the whitespace, but then added it when it shows the response! I once spent half an hour trying to switch off "autoformatting" on the server, until I noticed that Bruno adding it!

image

On the other hand, when I click "generate code", then half of the options show both keys in the bodies, the other half just one:

Http:

POST / HTTP/1.1
Host: localhost:3000
Content-Length: 37

{
  "hi": "there",
  "hi": "there2"
}

Javascript-Fetch

const url = 'http://localhost:3000/';
const options = {method: 'POST', body: '{"hi":"there2"}'};

try {
  const response = await fetch(url, options);
  const data = await response.json();
  console.log(data);
} catch (error) {
  console.error(error);
}

Javascript-JQuery

const settings = {
  async: true,
  crossDomain: true,
  url: 'http://localhost:3000/',
  method: 'POST',
  headers: {},
  processData: false,
  data: '{\n  "hi": "there",\n  "hi": "there2"\n}'
};

$.ajax(settings).done(function (response) {
  console.log(response);
});

Especially the http-code is misleading, because as a naive user, I would think that this is the raw packet on the wire.

If we support two backends, then the code-generators need to respect that setting so that they generate the actual request that is sent by Bruno.

But I don't want any of the magic that is applied by axios. I want to send and receive the requests exactly as they are. I think users that want to "auto-fixup" their requests are probably best served by a CLI script that runs over their bruno collection, possibly as pre-commit script. I'd be happy in assisting to write such a script -- I actually really care about standards. But I can only enforce standards-compliant servers (header-capitalization) when I can intentionally break the standard and/or see raw responses.

@mheidinger
Copy link
Contributor

mheidinger commented Apr 29, 2024

Thanks for starting this discussion, I think its crucial for many people (prob. especially security folks) to send requests with weird inputs / formatting / etc. exactly as they specified.

I would argue to switch to curl completely.

I fully agree with this statement. I would not expect a "normal" end-user to care about which library is used to send out the actual HTTP request until they hit some unexpected behaviour. For that there would be a need to document all the little things that work differently for the different backends (which is probably a list that may never be completed as new things might get discovered).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants