Unreliable connection between standalone Blockly and asebahttp

[ypiguet-epfl]

Sending an application from Thymio Blockly (standalone application) to asebahttp (whether launched by Thymio Web Bridge or directly) is very unreliable (tested in 1.6 on macOS 10.12 and Chrome 63, also with other web applications using an entirely different code base; Firefox is slightly better). Reloading the web page helps (except that the Blockly program is lost).

After initial investigation, a potential culprit could be that Chrome doesn't like the 204 status code sent by method PUT in http.cpp (method HttpInterface::evLoad). The XmlHttpRequest doesn't terminate successfully and discussions about this issue can be found on the web. A dummy reply with status 200 could be a solution.

[davidjsherman]

Can you show the error that you are seeing in the console log? I don't understand how you are performing this test. Could you be more specific in the steps?

The current 204 response conforms to RFC 7230 as well as standard practice, so I would need a lot of convincing before distorting the v1 API in order to work around browser bugs. A 200 response as you suggest sends the client to a new (empty) page, which wouldn't really be satisfactory, whereas a 204 allows the client to continue with the same contents.

Of course if the API were extended to be HATEOAS, in that case the responses would always be 200 because the switch would always be sending a new state with updated links.