-
Notifications
You must be signed in to change notification settings - Fork 44
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
Query parameters not correctly parsed #590
Comments
I believe |
I think it should not be consistent with the behavior of querystring, but with the HTTP RFC. I don't know what the exact result would be with the built-in node qs module, but having to write custom code for every field that you want to contain another type than string for every single function (except you are using durable then it's only the starter function) can't be solution. EDIT: I made a few checks and most of the query string parsing libraries I tested have this as optional and a few as default. query-string, qs and querystring have it as optional. |
I don't have a quick answer on this, but regardless it would be a breaking change so it probably wouldn't happen any time soon.
We're working on some new features that would make it easier for you to write code that would apply to all functions, which could help in this case. The feature is called invocation hooks and you could do something like this: import { registerHook } from '@azure/functions-core';
registerHook('preInvocation', (context) => {
// if context.req.query exists
// for (const [key, value] of Object.entries(context.req.query))
// try parse `value` as boolean
// try parse `value` as number
}); NOTE: this feature is still rolling out in Azure and we have not published a types package for "@azure/functions-core" yet.
I agree. The hooks mentioned above should help with code duplication, but we can look into providing specific options as well |
I understand, if it would help, I could create a PR to the docs with an example using the mentioned hooks. |
We're not ready to document the hooks feature yet. People can use hooks directly from the cc @davidmrdavid for the question on durable functions. My quick answer is that if it works for you then yes it's "good" 🙂 |
Are hooks now a fully documented and native ESM compatible feature @ejizba ? Since the last update, there was a lot of shifting towards nodeless edge worker environments for deployment. |
We switched to use a more standard Node.js type Hook support can be tracked here: https://github.com/Azure/azure-functions-nodejs-library/issues?q=is%3Aopen+is%3Aissue+label%3Ahooks |
The source code describes the type for the query parameters as being only string values
azure-functions-nodejs-worker/types/index.d.ts
Line 111 in d51a7b0
The following query would result in a JavaScript object that consist of only strings:
Repro steps
You can easily create a querystring by using e.g. the query-string library:
const testQs = queryString.stringify({param1: false, param2: 100, param3: 'test'});
.To get the correct results, it can then be parsed using the same library:
queryString.parse(testQs, {parseBooleans: true, parseNumbers: true});
.I couldn't find details on query parameter parsing on the Docs, things like supported types and array formats for query strings would really be helpful.
The text was updated successfully, but these errors were encountered: