#Weird behaviour of h3's readMultipartFormData on Azure

13 messages · Page 1 of 1 (latest)

idle lark
#

I'm using readMultipartFormData like this in a nitro endpoint :

const rawBody = await readMultipartFormData(event)
const rawFile = rawBody.find(partData => partData.name === 'receipt')

But the rawFile I'm getting seems to be corrupted or something that I can't really explain.
The file I'm uploading is 15Mb. When I'm testing on my local machine in dev mode, rawFile?.data.byteLength is correct and equals 14966
But when deployed to Azure (SWA + managed function) it's 21794

I genuinely have no idea what could explain this difference. The actual request in the browser is fine, and Content-Length is the same as when I test in local.
Anyone has experience with uploading files to a nitro backend on Azure, who noticed the same behaviour / how to fix it ?

kindred juniperBOT
#

Hi @idle lark. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

This issue appears to be related to how Nitro (the server engine that powers Nuxt) handles multipart form data when deployed to Azure, specifically with the readMultipartFormData function.

The behavior you're experiencing where the file size is different between your local development environment and Azure deployment is unusual. Based on the knowledge sources, there are a few potential explanations and approaches to troubleshoot:

  1. Nitro version differences: There have been several updates to Nitro recently that might affect how it handles requests. For example, in Nitro v2.11.7, there were fixes related to request handling and platform context in direct fetch operations.

  2. Headers and encoding issues: There might be differences in how Azure handles multipart form data compared to your local environment. The issue could be related to how the data is encoded or decoded during transmission.

  3. Content-Length mismatch: Although you mentioned the Content-Length is the same in both environments, there's a related issue in the knowledge sources about mismatching content-length causing errors which might provide some insight.

To troubleshoot this issue, you could try:

  1. Add logging: Log more details about the request and the file data in both environments to identify differences.

  2. Check for encoding issues: The difference in size (15Mb vs 21794 bytes) suggests there might be encoding or chunking issues.

  3. Try a Nitro plugin: You could implement a Nitro plugin to intercept and inspect the request before it reaches your handler:

# 
// server/plugins/debug-requests.ts
export default defineNitroPlugin((nitroApp) => {
  nitroApp.hooks.hook("request", (event) => {
    console.log("Request headers:", event.headers);
    // Additional debugging
  });
});
  1. Check Azure configuration: Ensure your Azure Static Web App and Function configurations are correctly set up for handling large file uploads.

Unfortunately, there isn't a specific documented solution for this exact issue in the knowledge sources. If the problem persists, you might want to:

  1. Open an issue on the Nuxt GitHub repository with detailed reproduction steps
  2. Check if updating to the latest version of Nuxt/Nitro resolves the issue
  3. Consider implementing a workaround such as using a different approach for file uploads (like direct Azure Blob Storage uploads from the client)

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@idle lark Kapa.ai is still learning and improving, please let me know how I did by reacting below.

idle lark
#

@kindred juniper the issue seems to come from the nitro preset, do you have a preset for azure functions v4 ?

kindred juniperBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources provided, there isn't specific information about a Nitro preset specifically for Azure Functions v4. However, your issue with readMultipartFormData behavior differences between local development and Azure deployment does appear to be related to the Nitro preset being used.

The knowledge sources indicate that Nitro presets are an important part of the deployment configuration. For example:

  1. There was a recent update to the Nitro preset directory as mentioned in this PR, which fixed issues related to preset handling.

  2. The nuxi build command supports a --preset flag as documented in this PR, which allows you to specify which Nitro preset to use during build.

For Azure deployments, you might want to try specifying the Azure preset explicitly when building your application:

nuxi build --preset azure

If you're experiencing issues with the current Azure preset, you could also:

  1. Check the current version of Nitro you're using, as there have been several updates that might affect how presets work.

  2. Consider creating a custom preset for Azure Functions v4 if one doesn't exist. This would involve creating configuration files that properly handle the multipart form data in the Azure Functions v4 environment.

  3. Open an issue on the Nitro GitHub repository specifically about Azure Functions v4 support, as this might be a gap in the current preset offerings.

#

The file size difference you're experiencing (correct size locally but larger on Azure) suggests there might be encoding or processing differences in how the Azure preset handles multipart form data compared to the local development environment.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@idle lark Kapa.ai is still learning and improving, please let me know how I did by reacting below.

idle lark
true kite
#

The issue is likely due to how Azure Functions handle multipart/form-data requests, which differs from local Node environments. The body parser middleware in Azure may buffer or transform binary payloads, especially when using proxies (like SWA's reverse proxy to functions).

drowsy viper
#

may be multer will work? 🙂