-
Notifications
You must be signed in to change notification settings - Fork 14
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
v4 programming model - req.json is returning Body is unusable for post with JSON #79
Comments
Try removing these lines:
The request body functions can be run only once; subsequent calls will resolve with empty strings/ArrayBuffers. |
That works for me. Thanks. |
What is the rationale behind making the body only available for a single request? There are plenty of times where we need to access the raw body to do things such as validate signatures from third parties for security purposes, those generally need the rawbody (v3). Then separately we want to do crazy things like pull keys out of the JSON that was sent to us. Currently our solution is to do a JSON.parse() on the text output, but somehow hash of the raw body is different than the hash of the parsed JSON, even though it is well formed. Love the v4 model, but wow there are some big differences that are making life harder. |
Hi @arlogilbert, good questions. First of all, we're leveraging a design by the much larger Node.js community called the fetch standard (some docs here). In the v4 model we wanted to leverage an existing design for http types instead of using one unique to Azure Functions. Other folks have asked your same question to the larger community, and here is one example. AFAIK, the primary reason is to allow the use of streams under the covers and by definition streams can only be read once. Using a stream has big performance and throughput benefits, so we've been preparing for that for a while. If you want to get into the nitty gritty, the functions implementation doesn't technically use a stream yet, but it will very soon and moving to these community-designed types was a first step in the process. I believe you're already following the recommended workaround, which is to call |
Thanks for the great explanation.
The workaround works ok, it was just a bit frustrating moving a function from 3 to 4 and discovering that functionality that was used pretty ubiquitously was now taken away.
With this particular call, it isn’t an easy search and replace, and because we always had the request object available, we often passed it into custom classes and myriad functions.
Just not an easy one to rip and replace.
The new folder structure is great though, and if we were starting from 0 it wouldn’t be an annoyance.
Thanks again.
— Arlo (mobile)
…________________________________
From: Eric Jizba ***@***.***>
Sent: Friday, December 15, 2023 1:40:02 PM
To: Azure/azure-functions-nodejs-library ***@***.***>
Cc: Arlo Gilbert ***@***.***>; Mention ***@***.***>
Subject: Re: [Azure/azure-functions-nodejs-library] v4 programming model - req.json is returning Body is unusable for post with JSON (Issue #79)
Hi @arlogilbert<https://github.com/arlogilbert>, good questions. First of all, we're leveraging a design by the much larger Node.js community called the fetch standard (some docs here<https://developer.mozilla.org/en-US/docs/Web/API/Response>). In the v4 model we wanted to leverage an existing design for http types instead of using one unique to Azure Functions. Other folks have asked your same question to the larger community, and here is one example<nodejs/undici#1208>.
AFAIK, the primary reason is to allow the use of streams under the covers and by definition streams can only be read once. Using a stream has big performance and throughput benefits, so we've been preparing for that for a while. If you want to get into the nitty gritty, the functions implementation doesn't technically use a stream yet, but it will very soon and moving to these community-designed types was a first step in the process.
I believe you're already following the recommended workaround, which is to call .text(), save that value, and then call JSON.parse on it when needed. It's not clear to me why that doesn't work for you, but if you elaborate with sample data and sample code I might be able to help.
—
Reply to this email directly, view it on GitHub<#79 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABOH5AMW2TXPOZQWG4HK5BLYJSRRFAVCNFSM6AAAAAAWZN76HKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJYGM4TQOJZG4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@ejizba I understand the design choice and looking forward to stream support. However, it would be beneficial to have an option to cache the request body. I'm writing a hook that validates the request body. The hook consumes it using Update: I've tried to use const textBody = await request.text()
parsedBody = JSON.parse(textBody)
// TODO: validate body here
const headerCopy: Record<string, string> = {}
origRequest.headers?.forEach((value, key) => {
headerCopy[key] = value
})
const queryParams: Record<string, string> = {}
origRequest.query?.forEach((value, key) => {
queryParams[key] = value
})
request = new HttpRequest({
method: origRequest.method,
url: origRequest.url,
body: { string: textBody },
headers: headerCopy,
query: queryParams,
params: origRequest.params,
}) |
@restfulhead moved your comment to a new issue: #207 |
Local development with new Node.js programming model.
I'm sending in JSON in a curl command:
I've also tried it with a data file from cURL as well as PostMan. I must be missing something. I have 2 functions, 1 uses req.text and parses the JSON which works. 1 reads the req.json and throws an error. Where am I going wrong with this? The undici-fetch error makes it look like I can't do a POST in the new runtime with JSON because their fix is to downgrade to Node 16.
Complete error:
The text was updated successfully, but these errors were encountered: