Some (but not all) static files fail to be served - ERR_CONTENT_LENGTH_MISMATCH

[jeremythille]

Issue

Setup:

• Deno Version: 1.17 (updated today)
• v8 Version: Not sure, the one shipped with Deno 1.17?
• Typescript Version: 4.5
• Opine Version: 2.0.0

Details

I am using Opine to serve my Angular application's static files. Angular's "dist" folder contains :

- index.html (2.2 KB)
- main.js (182 KB, development version, un-minified)
- polyfill.js (44 KB)
- runtime.js (1 KB) 
- styles.css (7.7 KB)

My server code :

import { opine, serveStatic } from "https://deno.land/x/[email protected]/mod.ts";
import { distDir } from "./utils.ts"

console.log(`distDir = `, distDir); // Logs "distDir =  D:\dev\Dwiki\front\dist", that's correct

const app = opine();

app.use(serveStatic(distDir)); 

app.get("/", (req, res) => res.sendFile(distDir + "/index.html"))

await app.listen(8090);

console.log(`App listening on http://localhost:8090`);

Result :

When I localhost:8090, some files get loaded, some don't :

- index.html (2.2 KB) --> OK 200
- main.js (182 KB) --> (failed)net::ERR_CONTENT_LENGTH_MISMATCH
- polyfill.js (44 KB)--> (failed)net::ERR_CONTENT_LENGTH_MISMATCH
- runtime.js (1 KB) --> OK 200
- styles.css ( 7.7 KB) --> OK 200

No error in the terminal or in the browser's console. All that's displayed in my terminal is :

distDir = D:\dev\Dwiki\front\dist
App listening on http://localhost:8090

If I serve my Angular app with ng serve, it displays correctly.

I can see the content of index.html, runtime.js and styles.css in the browser's network tab.
Not sure why some files are served correctly by Deno/Opine, and some (always these two) get (failed)net::ERR_CONTENT_LENGTH_MISMATCH

EDIT

I noticed the two files that fail to be served are also the two heaviest of the lot. I have updated my question, adding the weight of each file, above. It looks like small files (7 KB, 1 KB, 2 KB) are being served normally, but heavier files (44 KB, 182 KB) get ERR_CONTENT_LENGTH_MISMATCH

[xyzshantaram]

@jeremythille Hi! I've run into the same issue, and I'm wondering if you've found a workaround yet -- this is kind of a deal breaker...

[jeremythille]

@ No, actually I tried to remove Opine altogether and serve my files just with Deno, without a library, and so far it works well

[cmorten]

Heya @xyzshantaram, @jeremythille 👋

Do you have a minimal reproduceable example / gist / repo that I can use to try and debug this issue?

[jeremythille]

Ha, no sorry (and it's new year's eve, and then I'm going on a trip so I don't really have time to set up a repo now). But I've put my whole server code in my original question, apart from the Angular files which are really generic HTML/CSS/JS files. Thanks for looking into this issue, and of course, happy new year :)

[xyzshantaram]

@jeremythille That will work for a bit, I suppose.
@cmorten I can try to write one for you, it's a bit late where I am but I will try to post it by tomorrow!

[xyzshantaram]

@cmorten -- Here you go! https://github.com/xyzshantaram/opine-content-length-bug

Sorry I couldn't work on it last year ;)

[cmorten]

Thanks for the great repro @xyzshantaram!

I've identified the issue - with some of the changes moving to the new std/http server for 2.0.0 of opine a regression has been introduced where served files are now being closed before the stream has finished reading them.

I have an idea for a fix which can look into this afternoon 😄

The code has its own reader impl. which was needed originally, and to ensure resource cleanup this close loop was introduced. With the 2.0.0 changes we now use a readable stream for the response which is capable of closing the resource itself- suspect can bin off the hand rolled reader to fix the bug and also get a slight perf benefit 😄

[cmorten]

Hey @jeremythille @xyzshantaram I've just released 2.0.2 which I believe fixes the issue. If not please do reopen!

[jeremythille]

Hi Craig, thanks for the follow-up and the quick maintenance. Will try to test it later today or tomorrow. Cheers

…

On Sat, 1 Jan 2022 at 19:48, Craig Morten ***@***.***> wrote: Hey @jeremythille <https://github.com/jeremythille> @xyzshantaram <https://github.com/xyzshantaram> I've just released 2.0.2 which I believe fixes the issue. If not please do reopen! — Reply to this email directly, view it on GitHub <#151 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JAIEL7HBPS7XWMI6LYGLUT5EBXANCNFSM5KI62V4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[xyzshantaram]

Ah, crap, I forgot to respond to this! @cmorten thanks a lot for the prompt fix, it worked perfectly! <3

[jeremythille]

For the record, I still haven't tried @cmorten's fix, because I'm still trying to code a little server using native Deno code (for learning purposes, I want to understand how Deno works before using libraries), and I have the same issue without Opine.

For that matter, I have just opened a similar issue on Deno's repo: denoland/deno#13362

So... is it an Opine, or a Deno issue after all? :)

EDIT

It is a "me" issue! I forgot to encapsulate the inner await in an anonymous function, it works now. Sorry folks.