doc: ensure the link shown correctly in GitHub

.gitignore

@@ -22,6 +22,7 @@ test-envoy/
 # website
 site/public/
 site/resources/
+site/static/images
 site/.hugo_build.lock
 site/tmp
 # dev files

site/Makefile

@@ -29,5 +29,7 @@ clean:
 .PHONY: publish
 # The generated files will be under ./public
 publish:
+	test -d static || mkdir -p static
+	rm -rf static/images && cp -r ../images static/
 	# FIXME: change baseURL to real link
 	docker run --rm -v $(PWD):/src --name docsy htnn-docsy -- hugo --minify --gc --baseURL https://mosn.io/

site/content/en/docs/concept/consumer.md

@@ -82,7 +82,7 @@ spec:
 
 Without the Consumer layer of abstraction, each route would have to be configured with `key: Leo`. Imagine one day, for example, `Leo` is just a temporary user and we need to revoke their permissions. With the Consumer, we would only need to delete the consumer `Leo`, without any need to alter the route configurations.
 
-[Consumer plugins](../../developer-guide/plugin_development) can be configured within the `auth` field of a Consumer. There are two types of configurations for each Consumer plugin: one is set on the Route, which specifies the source of authentication parameters, such as the `keys` in the previously mentioned FilterPolicy. The second type is configured on the Consumer, which determines the matching authentication parameters for that specific Consumer, as exemplified by the `key` in the above Consumer.
+[Consumer plugins](../developer-guide/plugin_development.md) can be configured within the `auth` field of a Consumer. There are two types of configurations for each Consumer plugin: one is set on the Route, which specifies the source of authentication parameters, such as the `keys` in the previously mentioned FilterPolicy. The second type is configured on the Consumer, which determines the matching authentication parameters for that specific Consumer, as exemplified by the `key` in the above Consumer.
 
 Each Consumer plugin configured on the Route will proceed through the following steps:
 

site/content/en/docs/concept/filterpolicy.md

@@ -4,7 +4,7 @@ title: FilterPolicy
 
 Most businesses on gateways and service mesh revolve around network protocols, such as authentication, rate limiting, request rewriting, etc. HTNN abstracts these needs and uses FilterPolicy to express specific configuration rules.
 
-Unlike some similar products, HTNN does not use different CRDs for different business categories, but unifies all policy-level business needs using a single CRD, FilterPolicy. This is because we feel the cost of multiple CRDs is too high. We even introduced the `0 CRD` [embedded mode](../embedded_mode) to reduce the cost of integration and maintenance.
+Unlike some similar products, HTNN does not use different CRDs for different business categories, but unifies all policy-level business needs using a single CRD, FilterPolicy. This is because we feel the cost of multiple CRDs is too high. We even introduced the `0 CRD` [embedded mode](./embedded_mode.md) to reduce the cost of integration and maintenance.
 
 ## Structure of FilterPolicy
 
@@ -61,7 +61,7 @@ For specific examples of using `sectionName`, see the following.
 
 Currently, FilterPolicy can only affect route resources in the same namespace, and the targeted resource's Gateway must be in the same namespace as the resource.
 
-This FilterPolicy also includes a `filters` section. Multiple plugins can be configured within `filters`, such as `animal` and `plant` in the example. The execution order of each plugin is determined by the [order specified](../../developer-guide/plugin_development#plugin-order) when the plugin is registered. Each plugin's specific configuration is located in the `config` field under the plugin name.
+This FilterPolicy also includes a `filters` section. Multiple plugins can be configured within `filters`, such as `animal` and `plant` in the example. The execution order of each plugin is determined by the [order specified](../developer-guide/plugin_development.md#plugin-order) when the plugin is registered. Each plugin's specific configuration is located in the `config` field under the plugin name.
 
 Like other Kubernetes resources, the HTNN control plane will modify the `status` field of the FilterPolicy to report the status of the policy. The `reason` field under `status` will be one of the following values:
 
@@ -77,7 +77,7 @@ Note: Restarting or upgrading the HTNN control plane will not actively re-valida
 
 ## Configuring Policies with FilterPolicy in Different Scenarios
 
-For gateways configured by API dimension, we can define a VirtualService for each API and then define an FilterPolicy pointing to it:
+For gateways configured by API dimension, we can define a VirtualService for each API and then define a FilterPolicy pointing to it:
 
 ```yaml
 - apiVersion: networking.istio.io/v1beta1
@@ -117,7 +117,7 @@ For gateways configured by API dimension, we can define a VirtualService for eac
 
 Under the same domain, different APIs will use different VirtualServices, and consequently, have different FilterPolicies.
 
-For gateways configured by domain dimension, we can define a VirtualService for each domain, and then designate an FilterPolicy to point to it:
+For gateways configured by domain dimension, we can define a VirtualService for each domain, and then designate a FilterPolicy to point to it:
 
 ```yaml
 - apiVersion: networking.istio.io/v1beta1
@@ -244,7 +244,7 @@ Take the following configuration as an example:
           pet: goldfish
 ```
 
-When we issue an FilterPolicy targeting a Gateway, all routes under the LDS generated by that Gateway (here referring to ports 80 and 443) will have the `animal` plugin configured.
+When we issue a FilterPolicy targeting a Gateway, all routes under the LDS generated by that Gateway (here referring to ports 80 and 443) will have the `animal` plugin configured.
 
 We can also use `sectionName` to specify the configuration to be issued to port 443:
 

site/content/en/docs/concept/service_registry.md

@@ -9,5 +9,5 @@ Manually managing `ServiceEntry` can solve some simple scenarios, but it is not
 Currently, HTNN has provided an implementation for Nacos V1, and we welcome contributors to submit code to support more service discovery systems.
 
 Relevant links:
-* [How to develop a registry](../../developer-guide/registry_development)
-* [Existing registry documentation](../../reference/registries)
+* [How to develop a registry](../developer-guide/registry_development.md)
+* [Existing registry documentation](../reference/registries)

site/content/en/docs/developer-guide/get_involved.md

@@ -38,7 +38,7 @@ HTNN places data plane-running Go Plugins and their shared pkg libraries in the
 
 If you want to write a Go Plugin in a third-party repository, you can refer to this example: https://github.com/mosn/htnn/tree/main/examples/dev_your_plugin. Go Plugins are compiled into shared libraries and deployed to the data plane. When you want to integrate a Go Plugin into the data plane, this file can serve as a template: https://github.com/mosn/htnn/blob/main/examples/dev_your_plugin/cmd/libgolang/main.go.
 
-It is recommended to read the existing plugins' code before developing your own plugin, especially plugins that are similar to the one you're developing – at the very least, you should look at the [demo](https://github.com/mosn/htnn/tree/main/plugins/plugins/demo) plugin. Plugin code is located in the `plugins/` directory. For more information on plugin development, please refer to the [Plugin Development](./plugin_development) documentation.
+It is recommended to read the existing plugins' code before developing your own plugin, especially plugins that are similar to the one you're developing – at the very least, you should look at the [demo](https://github.com/mosn/htnn/tree/main/plugins/plugins/demo) plugin. Plugin code is located in the `plugins/` directory. For more information on plugin development, please refer to the [Plugin Development](./plugin_development.md) documentation.
 
 HTNN provides a [Plugin Integration Test Framework](./plugin_integration_test_framework) that allows the testing of Go Plugin logic to run with only the data plane running. The `dev_your_plugin` example also demonstrates how to run the integration test framework in a third-party repository.
 

site/content/en/docs/developer-guide/plugin_development.md

@@ -15,7 +15,7 @@ Assume you are at the root of this project.
 5. Create a directory under `./plugins/plugins/`, with the same name created in step one. Finish the plugin. Don't forget to write tests. If your plugin is simple, you can write integration test only. You can take `./plugins/plugins/demo` as an example. The doc of the API used in the plugin is in their comments.
 6. Add the doc of the plugin in the `site/content/$your_language/docs/reference/plugins/$your_plugin.md`. You can choose to write doc under Simplified Chinese or English, depending on which is your prime language. We have [tool](https://github.com/mosn/htnn/tree/main/site#cmdtranslator) to translate it to other languages.
 7. Add your plugin's package into `./plugins/plugins.go`. Go to `./plugins`, then run `make build-so`. Now the plugin is compiled into `libgolang.so` under the current directory.
-8. Add integration test in the `./plugins/tests/integration/`. For how to run the integration test, please read [Plugin Integration Test Framework](../plugin_integration_test_framework).
+8. Add integration test in the `./plugins/tests/integration/`. For how to run the integration test, please read [Plugin Integration Test Framework](./plugin_integration_test_framework.md).
 
 You can also write the plugin outside HTNN project, please see [the guide to modify HTNN](./get_involved.md).
 
@@ -144,7 +144,7 @@ Currently, `DecodeRequest` is not supported by plugins whose order is `Access` o
 
 ## Consumer Plugins
 
-Consumer plugins are a special type of Go plugin. They locate and set a [consumer](../../concept/consumer) based on the content of the request headers.
+Consumer plugins are a special type of Go plugin. They locate and set a [consumer](../concept/consumer.md) based on the content of the request headers.
 
 A consumer plugin needs to meet the following conditions:
 

site/content/en/docs/operations-guide/architecture/istio.md

@@ -28,5 +28,5 @@ HTNN's distribution of Istio is 100% compatible with the official Istio release.
 | HTNN_ENABLE_LDS_PLUGIN_VIA_ECDS    | Boolean | false             | Enables the capability to deploy LDS plugins via ECDS.                                                                                                                                     |
 | HTNN_ENVOY_GO_SO_PATH              | String  | /etc/libgolang.so | The path to the Go shared library in the data plane image.                                                                                                                                 |
 | HTNN_ENABLE_NATIVE_PLUGIN          | Boolean | true              | Allows configuring Native plugins via the HTNN controller.                                                                                                                                 |
-| HTNN_ENABLE_EMBEDDED_MODE          | Boolean | true              | Enables [embedded mode](../../concept/embedded_mode).                                                                                                                                      |
+| HTNN_ENABLE_EMBEDDED_MODE          | Boolean | true              | Enables [embedded mode](../../concept/embedded_mode.md).                                                                                                                                      |
 | HTNN_USE_WILDCARD_IPV6_IN_LDS_NAME | Boolean | false             | Use a wildcard IPv6 address as the default prefix in the LDS name. Turn this on if your gateway is listening to an IPv6 address by default.                                                |

site/content/en/docs/reference/plugins/cel_script.md

@@ -4,7 +4,7 @@ title: CEL Script
 
 ## Description
 
-The `celScript` plugin determines whether the current request can access the upstream by executing the user-configured [CEL expressions](../../expr). Compared to static Go code, CEL expressions allow dynamic runtime configuration. Compared to complex rule files, CEL expressions execute faster. Compared to Lua scripts, CEL expressions run in a sandboxed environment, which is more secure.
+The `celScript` plugin determines whether the current request can access the upstream by executing the user-configured [CEL expressions](../expr.md). Compared to static Go code, CEL expressions allow dynamic runtime configuration. Compared to complex rule files, CEL expressions execute faster. Compared to Lua scripts, CEL expressions run in a sandboxed environment, which is more secure.
 
 ## Attribute
 

site/content/en/docs/reference/plugins/debug_mode.md

@@ -23,7 +23,7 @@ The `debugMode` plugin is used to enable debug mode on the targeted Route.
 
 | Name      | Type                            | Required | Validation | Description                                                                 |
 |-----------|---------------------------------|----------|------------|-----------------------------------------------------------------------------|
-| threshold | [Duration](../../type#duration) | True     | > 0s       | If the request takes longer than this time, print an error log as shown below. |
+| threshold | [Duration](../type.md#duration) | True     | > 0s       | If the request takes longer than this time, print an error log as shown below. |
 
 ## Usage
 

site/content/en/docs/reference/plugins/ext_auth.md

@@ -26,24 +26,24 @@ The `extAuth` plugin sends an authorization request to an authorization service
 | Name                  | Type                                | Required | Validation        | Description                                                                                                                                               |
 | --------------------- | ----------------------------------- | -------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | url                   | string                              | True     | must be valid URI | The uri to the external service, like `http://ext_auth/prefix`. The path given by the uri will be used as the prefix of the authorization request's path. |
-| timeout               | [Duration](../../type#duration)     | False    | > 0s              | The timeout duration. For example, `10s` means the timeout is 10 seconds. Default to 0.2s.                                                                |
+| timeout               | [Duration](../type.md#duration)     | False    | > 0s              | The timeout duration. For example, `10s` means the timeout is 10 seconds. Default to 0.2s.                                                                |
 | authorizationRequest  | AuthorizationRequest                | False    |                   |                                                                                                                                                           |
 | authorizationResponse | AuthorizationResponse               | False    |                   |                                                                                                                                                           |
-| statusOnError         | [StatusCode](../../type#statuscode) | False    |                   | Sets the HTTP status that is returned to the client when the authorization server returns an error or cannot be reached. The default status is `401`.     |
+| statusOnError         | [StatusCode](../type.md#statuscode) | False    |                   | Sets the HTTP status that is returned to the client when the authorization server returns an error or cannot be reached. The default status is `401`.     |
 | withRequestBody       | bool                                | False    |                   | Buffer the client request body and send it within the authorization request.                                                                              |
 
 ### AuthorizationRequest
 
 | Name         | Type                                    | Required | Validation   | Description                                                                                                                                               |
 | ------------ | --------------------------------------- | -------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| headersToAdd | [HeaderValue[]](../../type#headervalue) | False    | min_items: 1 | Sets a list of headers that will be included in the request to authorization service. Note that client request header of the same key will be overridden. |
+| headersToAdd | [HeaderValue[]](../type.md#headervalue) | False    | min_items: 1 | Sets a list of headers that will be included in the request to authorization service. Note that client request header of the same key will be overridden. |
 
 ### AuthorizationResponse
 
 | Name                   | Type                                           | Required | Validation   | Description                                                                                                                                                                     |
 | ---------------------- | ---------------------------------------------- | -------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| allowedUpstreamHeaders | [StringMatcher[]](../../type#stringmatcher) | False    | min_items: 1 | When this is set, authorization response headers that have a correspondent match will be added to the original client request. Note that coexistent headers will be overridden. |
-| allowedClientHeaders   | [StringMatcher[]](../../type#stringmatcher)    | False    | min_items: 1 | When this is set, authorization response headers that have a correspondent match will be added to the client's response when the request is rejected.                           |
+| allowedUpstreamHeaders | [StringMatcher[]](../type.md#stringmatcher) | False    | min_items: 1 | When this is set, authorization response headers that have a correspondent match will be added to the original client request. Note that coexistent headers will be overridden. |
+| allowedClientHeaders   | [StringMatcher[]](../type.md#stringmatcher)    | False    | min_items: 1 | When this is set, authorization response headers that have a correspondent match will be added to the client's response when the request is rejected.                           |
 
 ## Usage
 

site/content/en/docs/reference/plugins/inner_ext_proc.md

@@ -16,7 +16,7 @@ As Envoy uses an onion model to proxy requests, the execution order is:
 6. Run other plugins to process the response
 7. Request ends
 
-Please refer to the [outerExtProc](../outer_ext_proc) plugin documentation to learn how to use it. Do not forget to replace `outerExtProc` with `innerExtProc` when testing examples.
+Please refer to the [outerExtProc](./outer_ext_proc.md) plugin documentation to learn how to use it. Do not forget to replace `outerExtProc` with `innerExtProc` when testing examples.
 
 ## Attribute
 

site/content/en/docs/reference/plugins/inner_lua.md

@@ -16,7 +16,7 @@ Because Envoy uses the onion model to proxy requests, the execution order is:
 6. running other plugins with the response
 7. request ends
 
-Please refer to [outerLua](../outer_lua) plugin documentation to know how to use it. Don't forget to replace `outerLua` with `innerLua` when testing the example.
+Please refer to [outerLua](./outer_lua.md) plugin documentation to know how to use it. Don't forget to replace `outerLua` with `innerLua` when testing the example.
 
 ## Attribute