Skip to content
This repository has been archived by the owner on Dec 30, 2022. It is now read-only.

Wrong content-type header sent with requests #3487

Closed
tremby opened this issue May 28, 2022 · 3 comments
Closed

Wrong content-type header sent with requests #3487

tremby opened this issue May 28, 2022 · 3 comments

Comments

@tremby
Copy link

tremby commented May 28, 2022

馃悰 Bug description

Requests are sent in JSON format, but with the header content-type: application/x-www-form-urlencoded.

The Algolia server doesn't seem to mind; nothing is broken except the dev tools' view of the request.

馃攳 Bug reproduction

Steps to reproduce the behavior:

  1. Set up react-instantsearch-hooks-web, add a SearchBox.
  2. Type something in the box to cause a request
  3. See the network tab in dev tools, inspect the request
  4. See the outgoing headers and data

馃挱 Expected behavior

Correct header is sent (content-type: application/json)

馃枼 Screenshots

Here you see the request header has the wrong content type.
screenshot 1

This is what Firefox renders in the request tab -- it's declared as URLencoded form data so it's been split at & symbols and key-value pairs split at = symbols.
screenshot 2

If you flip to "raw" view you can see it's really JSON data.
screenshot 3

Environment

  • OS: n/a
  • Browser: n/a (screenshots are firefox)
  • Version: algoliasearch 4.13.1, react-instantsearch-hooks-web 6.26.0
@Haroenv
Copy link
Contributor

Haroenv commented May 30, 2022

This is actually on purpose to make sure we use something called a Simple Request to avoid a network request for the CORS OPTIONS.

The payload is indeed not easy to read sometimes, but I've (personally) made a tool to easily read the parameters as an object again: https://haroen.me/algolia-tools/#request-explorer

@Haroenv Haroenv closed this as completed May 30, 2022
@tremby
Copy link
Author

tremby commented May 30, 2022

Maybe text/plain would be better, then? It'd at least be readable without special addons.

@Haroenv
Copy link
Contributor

Haroenv commented May 31, 2022

I didn't know the engine changed to support text/plain as well, and that would be a better choice indeed. For now I'm not sure if eg. a special backend passed with "hosts" deals with that correctly, so changing it would be too risky to do in a non-major version.

In a next major version we're planning we are already changing the request to not use params anymore, but pass all values directly in the body which is much more readable already, even with the wrong content-type. I'll bring this topic up and see if it makes sense to change it in that major version to text/plain as well.

For the time being if you want to pass the content type yourself, you can do that:

algoliasearch('', '', { headers: { 'content-type': 'text/plain' }});

(in a sandbox: https://codesandbox.io/s/kind-goldwasser-z4335j?file=/src/App.tsx:308-463)

Haroenv added a commit to algolia/api-clients-automation that referenced this issue May 31, 2022
in algolia/react-instantsearch#3487 I discovered the text/pain content-type is also accepted by the engine, and also doesn't create a full CORS request
Haroenv added a commit to algolia/api-clients-automation that referenced this issue May 31, 2022
In v4 these are all allowed, and this allows users to work around possible issues we have smoothly, see eg. algolia/react-instantsearch#3487

At the same time I also simplified the passing of options in node/browser, they were double checking a variable that later overrides the original with the spread anyway.

Note to self: #614 touches a similar part of the code, whichever merges last will have to deal with a conflict
Haroenv added a commit to algolia/api-clients-automation that referenced this issue May 31, 2022
In v4 these are all allowed, and this allows users to work around possible issues we have smoothly, see eg. algolia/react-instantsearch#3487

At the same time I also simplified the passing of options in node/browser, they were double checking a variable that later overrides the original with the spread anyway.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants