Content length mismatch for modules when accessing dev server through android emulator

[ajscott-hcs]

Describe the bug

As part of upgrading one of our sites to use Vite, we have ran into an issue when accessing the dev server on various android emulators.

The issue seems to maybe stem from the web sockets / hot module reload, but unsure as each "fix" we have attempted hasn't proven fruitful and the access via the emulator remains flaky. When it fails the tab remains a white screen.

Below is the screenshot of the exact error when accessing the chrome inspector for emulators via chrome://inspect/#devices (to see the network tab)

The content that is required to be transferred appears to be larger than the expected content-length from the vite dev server.

Removing the sass aspect of the App.scss did not resolve the issue, only moved it to another module (e.g., MUI).

I have attached a repo with a minimal reproduction and response content. The only other issue that seems related is this closed issue.

Reproduction

https://github.com/ajscott-hcs/vite-dev-android

Steps to reproduce

Steps are wtihin the top level readme of the repro repo, but will add here for brevity.

1. npm install
2. npm run tailwind
3. npm run dev

Ensure you also have an android emulator running, this currently has been tested against the following emulators:

• pixel 5 api 31
• pixel 6 api 33
• pixel 7 api 33
• pixel 9 api 35

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-1260P
    Memory: 4.23 GB / 31.61 GB
  Binaries:
    Node: 21.7.1 - C:\Program Files\nodejs\node.EXE
    npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (134.0.3124.66)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    @vitejs/plugin-react: ^4.3.4 => 4.3.4
    vite: ^6.2.0 => 6.2.5

Android Emulator SDK: 35.4.9

Used Package Manager

npm

Logs

Reponse content
"response": {
"status": 200,
"statusText": "OK",
"httpVersion": "HTTP/1.1",
"headers": [],
"cookies": [],
"content": {
"size": 3774708,
"mimeType": "text/css",
"compression": 10815
},
"redirectURL": "",
"headersSize": 237,
"bodySize": 3763893,
"_transferSize": 3764130,
"_error": "net::ERR_CONTENT_LENGTH_MISMATCH"
},

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sapphi-red]

I've checked if I can reproduce it but it worked fine on my machine. I guess you have to debug the reason on your own.

[ajscott-hcs]

I've checked if I can reproduce it but it worked fine on my machine. I guess you have to debug the reason on your own.

@sapphi-red What setup did you use? It's been successfully repro'd on a few machines so it's odd that it didn't on yours

[sapphi-red]

I used Android emulator 35.4.9-13025442 + Pixel 9 API 35 on Windows 11.

[sapphi-red]

It looks like you are accessing the Vite dev server via 10.0.0.0/n. Maybe there's a proxy or something similar modifying your content?

[ajscott-hcs]

Could I trouble you to also test on a lower version of the android API? specifically 31

There isn't any proxy setup, it's how the emulator is able to get to localhost when it runs on the same machine

[sapphi-red]

I've tested with Pixel 5 + API 31 now, but it doesn't reproduce.

[ajscott-hcs]

Drats, thank you for testing again for me. Hopefully someone else will be able to repro it with more knowledge about the bundling and serving side of the vite dev server

[safakdinc]

did you make any progress? i encountered same error with nuxt 3 developtment server. it's not happens with vue 3 somehow.
for reproduction just create a fresh nuxt 3 project and start dev server with nuxt dev --host. it will open dev server to network. then you can try open it in android emulator.

[ajscott-hcs]

Haven't been able to make any progress, other than narrowing down the issue to be with Dell-based computers. I was able to test this on a few different makes and models and they worked - except Dells

[geminigeek]

exact same problem using windows 11 , nuxt 4 . but the app runs fine on physical android device, anyone found a fix for this ?

[geminigeek]

did you make any progress? i encountered same error with nuxt 3 developtment server. it's not happens with vue 3 somehow. for reproduction just create a fresh nuxt 3 project and start dev server with nuxt dev --host. it will open dev server to network. then you can try open it in android emulator.

can you open the dev server in chrome which is in emulator device ? , its seems like cors and nitro issue with nuxt

[qoo1476]

Have you found the cause?
I'm experiencing the same issue. In Nuxt, I cannot access the dev server from an Android emulator.

[chine]

I may have run into this issue as well.

I'm on a Dell, running an Ionic/Capacitor app built with vite.

I suppressed the header causing the CONTENT_LENGTH_MISMATCH which revealed INCOMPLETE_CHUNKED_ENCODING errors, and then suppressed that header too; from vite.config:

    plugins: [...
      {
        name: 'remove-content-length-and-transfer-encoding',
        configureServer(server) {
          server.middlewares.use((req, res, next) => {
            res.removeHeader('Content-Length');
            res.removeHeader('Transfer-Encoding');
            next();
          });
        }
      }
    ...],

At that point I began seeing this error:

Which looks to be cause by lack of an "e" in this "let"

I checked the source in my node_modules and the line is correct there.

I can also confirm that I do not encounter the error when accessing the vite dev server outside of the application, directly in a browser.

vite: ^5.0.0
Android Studio 2025.1.1
Android 13, API 33

[chine]

And now I find this to have mysteriously started working again. Not sure what has changed to resolve it.