socket - ERR_CONNECTION_RESET on 4th connection

[nagylzs]

I have managed to overcome this problem (partly) with a javascript trick. The main html page is not the real main page but a "loader". There I use plain javascript code to preload all required resources from the micropython server synchronously. E.g. I do a fetch request, and wait until it is completed. Then I invoke the next fetch etc. The list of required resources is pre-computed and stored in a javascript array. Most of the resources are stored in the browser cache, and the javascript code makes sure that only one request is made at a time. After the last resource has been loaded (and cached), the browser is redirected to the "real" main page. That page will use all resources from the browser cache. This trick can be used to server complete SPA (single page application) websites with multiple CSS Javascript, web font etc. files. The only thing you need to make sure is that static resources are returned with a non-zero max-age cache header. (Of course, you should return no-cache headers for API calls, and you must make sure that only a single API is called at a time, but that can be easily achieved.)

If anyone is interested, I can post some example code.

[nagylzs]

Instead of making an example code, I made a complete project that does automatic wifi setup with a http/browser based gui.

https://github.com/nagylzs/micropython-wifi-setup

I need to translate the React/HTML code because it is still in Hungarian.

[cefn]

See the issue comment at https://github.com/micropython/micropyt ... -264750573 which links to a workaround; using NPM's inliner package to turn any multi-file HTML resource into a single file by auto-inlining all resources. Not a direct answer to ESP8266 socket failings, but it might help future developers hitting this same issue.

[cefn]

Worth noting also that Chrome has developed a mind-of-its-own webserver resource hoarding strategy known as Preconnect. https://www.chromium.org/developers/des ... preconnect

This strategy makes extra spare parallel connections to a server you are accessing, in case your browser might need them, based allegedly on some AI heuristics. These connections are made but no bytes are ever sent down them, so they may not behave as expected by a regular cooperative browser connection (e.g. any synchronous blocking read of the preconnect client socket will block indefinitely until Chrome decides to use the socket or to abandon it after some unpredictable timeout).

Because of the impact of this extreme behaviour ( which several embedded developers have been ranting to Google about, with no joy https://bugs.chromium.org/p/chromium/is ... l?id=85229 ) I was forced to rebuild my own webserver in asyncio, in which the concurrency permits multiple 'blocked' client sockets from coexisting in their blocked state, while any client sockets which become active can be served in a timely way.

You can see the project at https://github.com/vgkits/corequest/

A pluggable async handler gets called at https://github.com/vgkits/corequest/blo ... sts.py#L36
You can see the typical Preconnect error cases handled at https://github.com/vgkits/corequest/blo ... sts.py#L40 when they eventually time out.