Except for creating rules by filling in forms, we can also have custom Edge language rules for more complicated rules. The Edge language is a demand-specific language designed by ourselves. It can very precisely and efficiently describe various different kinds of gateway logic.

Here we have some Edgelang rules run after those form-based rules. Each rule has an arrow symbol to separate conditions and actions. As we can see that the conditions can be nested. And then we can also use regular expressions. For other details, we have an Edge Language User Reference Manual for you to look at.

And we can also add some Edge language rules at the beginning, before form-based rules.

For example, we add 'uri("/hello")' then generate a response body like "hello world".

So this rule will be triggered when the request URI is exactly /hello. As I mentioned before, configuration changes would require separate release operations to be made online.

Next we go yo the release page to see the unreleased change I just made.

We are at the release page where you can see the unreleased changes. We can clear this change, or release it to the cloud. And also we can see all the historical releases made before. Now let's make a new release so that we can actually test the gateway clusters directly.

We can watch the synchronization progress here, usually it takes only several seconds. Now let's test the gateway directly.

Let's pick up an edge node IP address.

And then open the command line. Using curl to test it.

$ curl --resolve 'openresty.org:80:' http://openresty.org/hello
hello world

We can see that this edge node already has this new rule applied.

We can also test it directly in the web browser.

Then go to openresty.org/hello.

We've got the "hello world" response.