-
Notifications
You must be signed in to change notification settings - Fork 391
Wrong content-type header sent with requests #3487
Comments
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 |
Maybe |
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 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) |
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
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
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.
馃悰 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:
react-instantsearch-hooks-web
, add aSearchBox
.馃挱 Expected behavior
Correct header is sent (
content-type: application/json
)馃枼 Screenshots
Here you see the request header has the wrong content type.
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.If you flip to "raw" view you can see it's really JSON data.
Environment
algoliasearch 4.13.1
,react-instantsearch-hooks-web 6.26.0
The text was updated successfully, but these errors were encountered: