Hi, I'm having issues coding an app in node.js aga...
# fleet
j
Hi, I'm having issues coding an app in node.js against the Fleet API. The Run Queries endpoint spec shows a GET with a JSON payload, which is against HTTP spec and node is actively refusing to do it.
k
Hey @J.R. Murray. You might have better luck getting advice in a Node space, but I'm happy to see if I can help. What package are you using to handle requests? It should certainly be doable. While sending a body in
GET
is unconventional, it isn't prohibited by spec.
j
@Kathy Satterlee thanks for the response. I would say it's contentious at best. https://github.com/node-fetch/node-fetch/pull/795
the error is
Request with GET/HEAD method cannot have body
m
We can def help you here. cc @Eric Shaw @Rachael Shaw
While sending a body in
GET
is unconventional, it isn't prohibited by spec.
💯 Agreed. Also found this weird. Here's how I implemented it in Node recently: (The TODO on line 167 can be ignored-- it turned out to be all good. I was just a little thrown off like you.)
j
We are using this as part of a security automation framework we're building... I don't think replacing the whole http architecture with
sails
is going to work unfortunately. I didn't write any of this code but I'm trying to shoehorn this in without rewriting too much, if possible.
m
Def wouldn't suggest that! Just sharing as an example of working code- feel free to implement it however you like.
Would you be able to share some code?
@koo might also have ideas
j
I can't share any code. Not that I don't want to, it's just complex and sprawled across a lot of files and functions. It's react in node.js.
honestly I'd just like another means to run a live query besides a get request, or to use the url query string for them
as it is, you can't put fleet behind varnish because it ignores any get payload and treats all of the requests the same
m
100% agree. And also re querystring. But as a short term workaround, how about switching to require(‘request’) or a different package, even if it’s just for this call? Want to make sure you’re unblocked. (We have a 3 week release cycle, except for security patches, and features get prioritized during the 3 weeks before the start of each sprint) If you’d like to contribute, an awesome immediate way could be to PR the API docs (“Edit this page”) and propose the API change to the docs themselves, with the context in this convo (where I think you’ve stated the problems with the current design very clearly and concisely) We need to take semver into account, but I think it’s doable in a backwards compatible way. Maybe we get that far, then Rachael (DRI) can review, and Kathy or Rachael can bring this up for prioritization at the next feature fest. Sound ok to you?
j
I'm ok with waiting 3-4 weeks for a fix. Having a working integration would be nice but I don't want to make a bunch of one-off code in a general-purpose solution. Not to mention I'm not really the developer 🙂
the code to make the request itself is relatively simple.
Copy code
response = await fetch(fetchUrl, {
        method: fetchMethod,
        headers: fetchHeaders,
        body: fetchBody
      })
m
To be clear: more like 6 weeks, if the CX group is able to prioritize it. I think the doc PR helps, since we can get that design worked out first asap; then it’s less scary to prioritize quickly
Also, super glad you brought this up. It’s a weird design that in retrospect should have been different, but didn’t realize you couldn’t do this kind of request in the most popular http client for at least one language. Def makes it more of a priority. cc @Rachael Shaw BOTL for a proposal
j
ok, that helps. Thank you 🙂
k
Great stuff y'all, thanks!
j
does someone have a github link for the api docs?
You can also hit the "Edit Page" button from the website on any page in the docs to be dropped right into and edit session on GitHub 🙂
j
neato
@Kathy Satterlee @mikermcneil have there been any updates on this?
m
@Noah Talerman @Rachael Shaw this API design decision was something I disagreed and committed on. It is possible to work around, but just weird and an easy change. I continue to disagree and I’m hearing users have the challenge.
j
FYI I just read that OpenAPI removed support for describing
GET
request bodies in version 3.0
m
As they should
j
apparently they quietly added it back into 3.1 after getting some pushback ... but yeah
m
Just a matter of timing. Should be a relatively small change, but would you be up for making a PR, JR?
j
I did a PR on the docs, we have too many backlogged items in our own app for me to commit to that.
m
I know the feeling FYI about the PR @Noah Talerman for feature fest.