[SOLVED] Chromium browsers fail to load texture files

Hi this is just a repost of my stackoverflow and chromium bug report post. But maybe some of you have an idea on why this is happening.

On a slow internet connection chromium browsers like Chrome and Edge fail to load texture files.

To reproduce, disable caching and set throttling to Fast 3G in Chrome. Then visit https://www.sick.com/tools/bas
Loading of image files will fail with error net::ERR_HTTP2_PROTOCOL_ERROR

For a more detailed description of the problem please checkout https://stackoverflow.com/questions/68711310/neterr-http2-protocol-error-for-large-png-files-on-throttled-slow-connection and https://bugs.chromium.org/p/chromium/issues/detail?id=1237907

EDIT: Firefox has no problems loading the files

How large are the PNGs?

Unfortunatly they are pretty large. This was a project of an intern. Im currently cleaning it up, but the error is still happening with files not greater than 1MB.

I try to get the cleaned up version running as soon as possible

Does this happen on a different server (like our playcanv.as)?

(Side note: consider using Basis texture compression as that can give much smaller files than the PNGs :slight_smile: )

It happens here: https://sick.com/tools/bas

But im pretty sure it also happens on the playcanvas server. I have to test that again

I can confirm i also receive the error on launch.playcanvas.com although way less. I had to revert my optimizations.

Very weird, not seen this before :thinking:

Ok so i tested a bit more and it looks like on launch.playcanvas.com the error only shows up for large files over 6 MB. After 6-7 minutes the download stops and chrome shows net::ERR_HTTP2_PROTOCOL_ERROR.
Maybe some server setting to prevent extremly long running connections?

Weird thing is Firefox has no problem with downloading the files and also takes more than 7 minutes to download large files

I’m can now produce error’s in Firefox as well. I’ll try to create a demo project tomorrow to showcase the issue.

Ok so i set up a test project:
Overview | Dashboard | HTTP Error Test | PlayCanvas | 3D HTML5 & WebGL Game Engine

When thottling set to Fast 3G in Chrome this will error with net::ERR_HTTP2_PROTOCOL_ERROR for http/2 and net::ERR_CONNECTION_RESET for http/1.1

Interestingly launch.playcanvas.com serves with http/2 and playcanv.as serves with http/1.1

http/1.1: https://playcanv.as/p/siPIHZzL/
http/2: https://launch.playcanvas.com/1210042

EDIT: On further inspection http/1.1 actually seems to work

EDIT 2: I also uploaded it to one of our server’s HTTP Error Test
Firefox with throttling set to Regular 3G loads as expected
Chromium browsers with throttling set to Fast 3G fail to load textures

@LucaHeft Are you still experiencing problems with this? We deployed some fixes related to the ERR_HTTP2_PROTOCOL_ERROR issue today. I’m hoping this also addresses what you describe here.

@will I just tested again and received the same error. But i’m pretty confident, that this is a Chromium bug as Firefox has no problems with loading the textures.

By the way you should be able to test this yourself. The playcanvas project should be public. If it doesn’t work let me know.

Thanks for the investigation in the problem though!

I can not reproduce the issue anymore. Chrome was updated since the issue was posted and we upgraded our asset delivery system recently so please check your tests again.

https://launch.playcanvas.com/1210042 successfully loaded in 13 min with disabled cache and Fast 3G throttling

I am closing the issue, but please re-open if you think it’s necessary.

3 Likes

I can confirm on launch.playcanvas.com it seems to work.
On our apache server i now get ERR_CONNECTION_CLOSED HTTP Error Test

So i guess it’s wrong server configuration on our side. What exactly did you change to get it working?

We launched new asset delivery system using CDN (blog post this week). The previous system used streaming from AWS S3, which had issues in some edge cases. When Fast3G throttling enabled and 3Mb assets, sockets to deliver assets from server are opened too long, so timeouts happened (at least on our side). I would suggest to try to play with timeout setting on your side, it may help (if it’s important)