This is the implementation of the WebAssembly http(s) transport layer that is used by libgit2. Previously a much simpler version of this was added as a patch to the libgit2 emscripten-forge recipe, this will instead add it to the git2cpp code base and is registered at runtime with libgit2 to handle http(s) transport using a scope object that is a no-op outside of WebAssembly.

I have tested this using a local CORS proxy server and it can access github and gitlab repositories, both public ones and private ones using a personal access token. No doubt changes will be required to work with other git servers and/or CORS proxies, which I will address in time.

The code itself is a combination of the C code that libgit2 expects and the C++ of the rest of git2cpp. In places there is tension between the two, I have tried to implement a middle ground so that the architecture is not too different from that used within libgit2 but we gain the benefit of core C++ classes such as strings and maps. As a result there is some code that is considered bad practice in C++ such as use of public member variables; I don't object to making it more C++-like but I am happy with it as it is.

The high-level architecture is that there is a callback create_wasm_http_transport registered with libgit2 that is called by any clone, fetch or push that uses http(s) to create a wasm_http_subtransport; there is a maximum of one subtransport per git2cpp command run. Each individual http(s) request calls wasm_http_action to create and use a wasm_http_stream, usually there is more than one request per command call. A stream works at a relatively high level calling JavaScript code (in EM_JS macros) to use a synchronous XMLHttpRequest. A single stream may actually use more than one request, for example if there is a redirect from http to https, or the requirement to enter credentials. Some of these extra requests are automatically handled by the browser or by the CORS proxy server, some of them are handled explicity in this new code. Information about redirects and authorisation credentials is stored at the subtransport level so that subsequent streams automatically use it without have to re-direct or re-request authorisation.

The JavaScript code in EM_JS macros is within .cpp files and subject to the linter's preferences. This is mostly OK as JavaScript is syntactically very similar to C++ but there are a few places containing JS syntax that causes problems, such as the ?? operator, and there are explicitly excluded from linting.