Hacker News Reader

Comment by papanoah | Hacker News Reader

I get this error on Firefox 90.0.2 on Debian 10. It works in chrome though.

[error: RuntimeError: abort(Error: Couldn't load https://phiresky.netlify.app/world-development-indicators-sq.... Status: 0). Build with -s ASSERTIONS=1 for more info.]

Other than that, is pretty awesome and exactly what I was hoping for.

View on HN

Looks like Netlify changed something since I wrote this article regarding what headers they send. Detecting support for Range-requests is kinda tricky and relies on heuristics [1]. Not sure why it still works in Chrome though.

You can go to this version of my blog, it should work there:

https://phiresky.github.io/blog/2021/hosting-sqlite-database...

Maybe the link could be updated?

Except for the DOM demo, since those need some Cross-Site-Isolation Headers you can't set on GitHub Pages (that's the reason I mirrored it to Netlify originally)

[1] https://github.com/phiresky/sql.js-httpvfs/issues/13

Maybe because Firefox is stricter? Netlify (incorrectly) sends a 4,583 byte chunk, while GitHub (correctly) sent precisely 1024 bytes. Chrome might just trim it to 1024 bytes, but Firefox just fail-safe at the difference.

Edit: Netlify is indeed wrong: asserts in the headers that the content length is 1024 bytes but sends up 4,583 bytes of content. That will definitely fail in Firefox.

And it doesn't seem like it'd be easy to get netlify to fix this type of behavior unfortunately: https://answers.netlify.com/t/add-unpacked-content-length-he...

Don't rely on browser implementation details and a hope that they won't break in the future. Add a small supplementary file to your published data which has a known pattern at a fixed offset, then make a request for that offset and check the response.

Browsers actually implement range-requests correctly, what Netlify has done is advertise support for it but send data incorrectly.

That doesn't change the thrust of the comment. If you're trying to work around spotty support and detecting the feature is "tricky", then change the program so it performs a small power-on self-test against a known dataset.

(And what's the point of crafting a comment in this tone? Is it supposed to be a retort? Whether or not Netlify is doing the wrong thing, if it works in Chrome, but not in Firefox, then that's a materially relevant fact. Don't rely on implementation details and a hope that they won't break in the future.)

Because both Chromium and Gecko follow the IETF (RFC)/W3C specs about this, what Netlify is doing is plain out-of-spec, so what Chromiun and Gecko are doing are implementation details that is explicitly marked as "okay, if you encounter a stupid server that is somehow explicitly advertising range-request support but does it incorrectly, you can do anything and you're still compliant". Drop the request (like Firefox)? Compliant. Silently trim (like Chrome)? Still compliant. Just give zeroes matching the announced length? Yes, still compliant even if you think that's stupid. If you didn't get this simple fact (that is easily verifiable by opening your favourite browser's devtools or even in Fiddler), I don't know how you're not getting this. Yes, it's using heuristics, but Netlify announces support for range-requests so there's no heuristics here to do, either Netlify must remove the header announcing support or Netlify fixes this problem before we talk about heuristics.

A bit late for the original discussion, but in case it helps future readers, I've filed https://github.com/whatwg/fetch/issues/1295 to see if we can get the spec and browsers aligned. (My guess is we will update the spec to allow this and Firefox will update to align with the new spec, since the direction of specs over time is always toward more-lenient.)

Reply on news.ycombinator.com