Rama 0.4: System proxy and PAC supportSkip to contentBack to blogRama 0.4: System proxy and PAC support<br>Six weeks after the release of 0.3 — nicely within the promised two-to-eight-week release train window — we are proud and happy to have shipped rama 0.4. It's a release that I am very happy with, as we were not only able to make tons of improvements here and there, but also got to work on some items that had been on our backlog for a long time.<br>Note<br>Are you new to Rama? Please read the introduction found in the project README, and afterwards you might want to read through the Rama 101 blog series.

For technical details please read the full CHANGELOG — including the rama 0.4 release notes — at https://github.com/plabayo/rama/blob/main/CHANGELOG.md. And at any time you can find a summary of what protocols and other features are supported in Rama at https://ramaproxy.org/#features.<br>System Proxy Configuration<br>Rama has had support for HTTP, HTTP over TLS (HTTPS) and SOCKS5 proxies for a long time. The easiest way is to configure them directly using ProxyRoute(s) (what used to be directly inserted as a ProxyAddress). Within applications these can be hardcoded or exposed via a setting somehow. An example of this is your browser or editor, which allows you to configure a proxy via a settings file or its GUI. You can read more about this approach in the "Application Proxies" chapter of the Rama book.<br>Applications often also support the HTTP_PROXY environment variable. curl uses the lowercase http_proxy variant instead for CGI reasons, a convention we now also follow by default when using the ProxyEnvLayer. That said, there are more common env variables, such as ALL_PROXY, HTTPS_PROXY and NO_PROXY, with the latter used to add bypass rules to, for example, ensure some (sub)domains do not go via a proxy. All of these are now also supported, via the ProxyEnvLayer and NoProxyEnvLayer.<br>However, as you might be aware, operating systems also allow you to configure a proxy system-wide. Here one can configure HTTP, HTTPS and SOCKS5 proxies, as well as bypass rules for what not to proxy. This is all very similar to the env variables discussed earlier, but system-wide. Of course, in general, nothing forces an app to respect these system configuration settings, either because it does not want to or because it simply does not have the built-in capacity to do so (which was the case for network clients built using rama, until now). With rama 0.4 this is supported out of the box via the SystemProxyLayer; you can learn more about how these settings work in the "System Proxies" chapter of the Rama book.<br>System configuration settings also allow you to have a proxy be dynamically selected using a JavaScript file. This is known as Proxy Auto Configuration, or PAC for short. To do so one must have a JavaScript runtime — not something rama shipped prior to rama 0.4. Now we do. With rama-js we now support running a JavaScript runtime within a WASM runtime (using wasmtime, the runtime we will also use in the future to build rama-wasm). This is important as it provides isolation, ensuring that if our JavaScript runtime crashes it doesn't take the whole process with it. Applications like Google Chrome run their JavaScript engine in a separate OS process; within the Rama framework we have chosen to do so within a WASM runtime instead. Same isolation, but without having to somehow allow any application built using Rama to run and bundle a separate process.<br>Rama now has PAC support, via the rama-pac crate, which allows you to have a PAC runtime, and thus evaluate PAC scripts, but also to easily generate scripts for cases where all you want is the ability to route domains X to proxy rules Y.<br>If you want to play with these new rama framework capabilities, you can also easily do so with our command line application (CLI), which you can learn how to install in the "rama binary" chapter of the Rama book:<br>Client send commands support it out of the box (unless you overwrite it with env variables or a command argument);<br>There are now rama pac subcommands allowing you to generate a PAC script as well as to evaluate a PAC script via a REPL. The latter is especially nice, as prior to this the only environments in which you could play with a PAC file were pretty old and obscure applications... Another nice addition to our network CLI toolkit if you ask me.<br>ttRPC and gRPC<br>Protocol-wise, rama now also has support for ttRPC, via the new rama-ttrpc crate. You can see it as a lightweight alternative to gRPC that runs directly on top of a transport protocol such as TCP, but still via a protobuf (proto) contract.<br>This is not the only new crate within this space however, as we now also have the rama-grpc-macros crate, bringing rama the ability to generate client- and server-side gRPC code without writing a single line of proto, relying instead on your own codecs, optionally driven by Serde (see define_service). Great for those that already use gRPC and are in...