Skip to content
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

431 Request Header Fields Too Large #4636

Closed
4 tasks done
liu-huitao opened this issue Mar 20, 2025 · 8 comments
Closed
4 tasks done

431 Request Header Fields Too Large #4636

liu-huitao opened this issue Mar 20, 2025 · 8 comments
Labels
upstream Related to the dependencies

Comments

@liu-huitao
Copy link

liu-huitao commented Mar 20, 2025

Describe the bug

Local error:

@pt_agentos.js?v=634b0a64:20203 
 GET http://localhost:5173/.vitepress/cache/deps/data:application/wasm;base64,AG…Nlc3NlZC1ieQIGd2FscnVzBjAuMjMuMgx3YXNtLWJpbmRnZW4SMC4yLjk5ICgwNGNhNmYzNGEp 431 (Request Header Fields Too Large)

@pt_agentos.js?v=634b0a64:20160 `WebAssembly.instantiateStreaming` failed because your server does not serve Wasm with `application/wasm` MIME type. Falling back to `WebAssembly.instantiate` which is slower. Original error:
 TypeError: Failed to execute 'compile' on 'WebAssembly': HTTP status code is not ok
@pt_agentos.js?v=634b0a64:21255 Failed to initialize Wasm module: CompileError: WebAssembly.instantiate(): BufferSource argument is empty
    at q4 (@pt_agentos.js?v=634b0a64:20168:30)
    at async d9 (@pt_agentos.js?v=634b0a64:20208:7)
    at async r19 (@pt_agentos.js?v=634b0a64:21253:7)
    at async Promise.all (index 0)
    at async f14 (@pt_agentos.js?v=634b0a64:21259:10)
    at async index.mts:70:9
index.mts:71 Uncaught (in promise) CompileError: WebAssembly.instantiate(): BufferSource argument is empty
    at q4 (@pt_agentos.js?v=634b0a64:20168:30)
    at async d9 (@pt_agentos.js?v=634b0a64:20208:7)
    at async r19 (@pt_agentos.js?v=634b0a64:21253:7)
    at async Promise.all (index 0)
    at async f14 (@pt_agentos.js?v=634b0a64:21259:10)
    at async index.mts:70:9

Image

Image

Image

Stackblitz case error:

See url: https://stackblitz.com/edit/vite-6uhev3lw

Image

Image

Reproduction

  1. Open the browser console.
  2. Refresh the page

Expected behavior

I hope to solve the issue of Status Code 431 so that Wasm initialization can be successful

System Info

System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
    Memory: 2.57 GB / 15.89 GB
  Binaries:
    Node: 20.18.0 - D:\Program Files\nodejs\node.EXE    
    Yarn: 1.22.22 - D:\Program Files\nodejs\yarn.CMD    
    npm: 10.8.2 - D:\Program Files\nodejs\npm.CMD       
    pnpm: 9.13.0 - D:\Program Files\nodejs\pnpm.CMD     
  npmPackages:
    vite: 4.5.3 => 4.5.3
    vue: ^3.4.38 => 3.4.38

Additional context

When adding the following configuration in the config. mjs file, it still doesn't work.

server: {
      headers: {
        maxHeaderSize: "20971520", 
      },
    }

No response

Validations

@liu-huitao liu-huitao added the bug: pending triage Maybe a bug, waiting for confirmation label Mar 20, 2025
@brc-dd brc-dd added upstream Related to the dependencies and removed bug: pending triage Maybe a bug, waiting for confirmation labels Mar 20, 2025
@brc-dd
Copy link
Member

brc-dd commented Mar 20, 2025

Most likely related to vitejs/vite#8427

new URL("data:application/wasm;base64,...", import.meta.url) is being incorrectly optimized.

If it's a separate package then it can be excluded using optimizeDeps.exclude. If it's not then you'll need to generate/patch the rust_lib.mjs such that it's just "data:application/wasm;base64,..." or if the wasm isn't inlined, then it should be a relative path I think. If patching after build isn't possible then something like this might work:

  vite: {
    plugins: [
      {
        name: 'fix-wasm',
        transform(code, id) {
          if (id.endsWith('.vitepress/theme/pkg/rust_lib.mjs')) {
            return {
              code: code.replace(/new URL\((".*"), import.meta.url\)/, '$1'),
              map: null
            }
          }
        }
      }
    ]
  }

@liu-huitao
Copy link
Author

I can confirm that this is indeed a separate package. We're using 'agentos-n' as an external dependency in our project, not as part of our codebase.

We've already implemented the optimizeDeps.exclude approach as you suggested:

optimizeDeps: {
  exclude: ['agentos-n'],
}

However, we're still encountering the issue with the WASM loading. The error occurs specifically when the package attempts to use new URL("data:application/wasm;base64,...", import.meta.url) construction.

Is there a way to apply your suggested plugin solution to an external package like 'agentos-n'? Or would we need to fork and modify the package itself to resolve this issue?
Please refer to the newly modified demo at https://stackblitz.com/edit/vite-6uhev3lw.
Due to the inability to install dependencies online in StackBlitz, I downloaded the demo project to my local computer to modify the code, but I still encountered the error '431 Request Header Fields Too Large', as shown in the supplementary image below.

Image

Image

@brc-dd brc-dd reopened this Mar 21, 2025
@brc-dd
Copy link
Member

brc-dd commented Mar 21, 2025

Seems like a bug with vite 5. It works fine with vite 6. (was fixed by vitejs/vite#18163)

Just this works fine:

import { componentPreview, containerPreview } from '@vitepress-demo-preview/plugin'
import { defineConfig } from 'vitepress'

export default defineConfig({
  markdown: {
    config(md) {
      md.use(containerPreview)
      md.use(componentPreview)
    }
  },
  vite: {
    resolve: {
      alias: [
        {
          find: /^vue$/,
          replacement: 'vue/dist/vue.esm-bundler.js'
        }
      ]
    },
    ssr: {
      noExternal: ['vue']
    }
  }
})
import { AntDesignContainer } from '@vitepress-demo-preview/component'
import '@vitepress-demo-preview/component/dist/style.css'
import { createPlugin } from 'agentos-n'
import { Theme } from 'vitepress'
import DefaultTheme from 'vitepress/theme'
import { onMounted } from 'vue'

export default {
  extends: DefaultTheme,
  enhanceApp({ app }) {
    app.component('demo-preview', AntDesignContainer)
  },
  setup() {
    onMounted(async () => {
      await createPlugin()
    })
  }
} satisfies Theme

no need to exclude from optimizeDeps either since it's using inline wasm. In dev there are some warnings regarding sourcemaps but I think they are from that container component. Probably can be ignored.

Change your deps to these, and delete lock file and node_modules and re-run npm install

{
  "private": true,
  "type": "module",
  "scripts": {
    "docs:dev": "vitepress dev docs",
    "docs:build": "vitepress build docs",
    "docs:preview": "vitepress preview docs"
  },
  "devDependencies": {
    "@vitepress-demo-preview/component": "^2.3.2",
    "@vitepress-demo-preview/plugin": "^1.4.0",
    "agentos-n": "^1.0.0",
    "js-base64": "^3.7.7"
    "vitepress": "next",
    "vue": "^3.5.13",
  }
}

@brc-dd brc-dd closed this as completed Mar 21, 2025
@liu-huitao
Copy link
Author

Thank you for solving my issue! I really appreciate your help.

I have one additional point to mention: Currently, the line import DefaultTheme from 'vitepress/theme'; in the file node_modules\vitepress\dist\client\app\index.js defaults to reading from docs\.vitepress\theme\index.ts. Is it possible to add support for docs\.vitepress\theme\index.mts as well?

This would provide more flexibility in our project structure and TypeScript module configuration.

@brc-dd
Copy link
Member

brc-dd commented Mar 24, 2025

@liu-huitao
Copy link
Author

I've found that this is supported in "vitepress": "latest", but not in "vitepress": "next". When using the "next" version, we encounter the following error:

Image

@brc-dd
Copy link
Member

brc-dd commented Mar 24, 2025

Seems like some vite bug. I'll try to find/create an issue there.

hmm vitejs/vite#18500

Please track #4644

Seems like resolve.extensions is not properly merged. Workaround:

vite: {
  resolve: {
    extensions: ['.mjs', '.js', '.mts', '.ts', '.jsx', '.tsx', '.json']
  }
}

@liu-huitao
Copy link
Author

Thanks for the update! 🙏 I'll track #4644 and a temporary workaround. Appreciate your help! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream Related to the dependencies
Projects
None yet
Development

No branches or pull requests

2 participants