Assets sometimes fail to load when testing html5 games

[Justin]

This was brought up on Discord as a new issue in the private builds of Stencyl.

When testing an HTML5 game in Chrome, the following error may occur:

Code: [Select]

[lime.utils.Preloader] ERROR: Error loading asset "{asset_name}"
GET http://localhost:18524/{asset_name} net::ERR_INVALID_HTTP_RESPONSE

I also noticed this for the first time the day after it was reported.

The last known "good build" was reported as b11017, but when I tested that build, the problem persisted. Perhaps this isn't caused by a change in Stencyl, but a change in Chrome. Firefox doesn't appear to be affected by this.

[Justin]

Here's a sample of http responses that are sent to the browser when assets are requested.

In this example, ext-unityads.xml is an asset that failed to load.

Code: [Select]

    (GET /assets/data/scene-26.scn HTTP/1.1)
HTTP/1.1 304 Not Modified \r\n
Content-Type: application/octet-stream\r\n
Date: Thu, 20 Oct 2022 04:22:09 GMT\r\n
Accept-Ranges: bytes\r\n
ETag: c08e243d\r\n
Connection: keep-alive\r\n
Content-Length: 0\r\n
\r\n

    (GET /assets/data/scene-27.scn HTTP/1.1)
HTTP/1.1 304 Not Modified \r\n
Content-Type: application/octet-stream\r\n
Date: Thu, 20 Oct 2022 04:22:09 GMT\r\n
Accept-Ranges: bytes\r\n
ETag: 87445082\r\n
Connection: keep-alive\r\n
Content-Length: 0\r\n
\r\n

    (GET /config/preloader-bg.txt HTTP/1.1)
HTTP/1.1 304 Not Modified \r\n
Content-Type: text/plain\r\n
Date: Thu, 20 Oct 2022 04:22:09 GMT\r\n
Accept-Ranges: bytes\r\n
ETag: 27c98e0a\r\n
Connection: keep-alive\r\n
Content-Encoding: gzip\r\n
Transfer-Encoding: chunked\r\n
\r\n
a\r\n
1f 8b 08 00 00 00 00 00 00 ff \r\n
a\r\n
03 00 00 00 00 00 00 00 00 00 \r\n
0\r\n
\r\n

    (GET /config/ext-unityads.xml HTTP/1.1)
HTTP/1.1 304 Not Modified \r\n
Content-Type: text/xml\r\n
Date: Thu, 20 Oct 2022 04:22:09 GMT\r\n
Accept-Ranges: bytes\r\n
ETag: 1ee95f17\r\n
Connection: keep-alive\r\n
Content-Encoding: gzip\r\n
Transfer-Encoding: chunked\r\n

This is for a page refresh, where most assets are already cached. Most assets are sent as-is, but text (like config/preloader-bg.txt) is gzipped and chunked.

Code: [Select]

Content-Encoding: gzip\r\n
Transfer-Encoding: chunked\r\n
\r\n
a\r\n (first chunk is 10 bytes)
1f 8b 08 00 00 00 00 00 00 ff \r\n
a\r\n (second chunk is 10 bytes)
03 00 00 00 00 00 00 00 00 00 \r\n
0\r\n (0, no more chunks)
\r\n

In this case, since it's not modified and there's no data to send, the chunked data is a stream of bytes which, when gunzipped, evaluates to nothing. This is a bit odd to me. Perhaps we should send a Content-Length: 0 response instead. But still, this is a new issue, and it only seems to happen in Chrome, so maybe something else is going on.

Viewing the http data through wireshark shows something a little more odd. I've cut it down now to only two resources, (1) /config/preloader-bg.txt and (2) /config/ext-unityads.xml.

Code: [Select]

(1) stencyl ← chrome HTTP GET /config/preloader-bg.txt HTTP/1.1
(1) stencyl → chrome TCP [ACK]
(1) stencyl → chrome HTTP HTTP/1.1 304 Not Modified
(1) stencyl ← chrome TCP [ACK]
(1) stencyl → chrome HTTP Continuation
(2) stencyl ← chrome HTTP GET /config/ext-unityads.xml HTTP/1.1
(1) stencyl → chrome HTTP Continuation
(1) stencyl ← chrome TCP [ACK]
(2) stencyl → chrome HTTP HTTP/1.1 304 Not Modified
(2) stencyl ← chrome TCP [RST, ACK]

My current interpretation is that Chrome isn't waiting for all of the continuation frames for the chunked data of preloader-bg.txt to be received before requesting the next resource. I'm not sure yet though, my mental model of this all is a bit shaky.

[Justin]

I tested with months-old versions of both Chrome and Stencyl, and curiously, the issue persisted. I'm not sure why it suddenly started.

I've fixed the problem by disabling chunked transfer encoding. HTML5 testing is mostly done locally anyway, so I don't think there's any perceivable performance gains to be lost here.

Stencyl 4.1.0-beta3-b11119.

• Tags added: 4.1.0
• Status changed from New to Resolved

• 4.1.0