final preparations

blog/2025-01-16-centrifugo-v6-released.md

@@ -375,7 +375,7 @@ Additionally, we've expanded the Grand Chat tutorial to include a [new chapter o
 
 Other improvements introduced in the v6 release include:
 
-* The ability to set custom [TLS configurations for internal](/docs/server/configuration#internal_tls) HTTP endpoints. Previously, it was only possible to disable TLS for internal endpoints while keeping TLS for external ones.
+* The ability to set custom [TLS configurations for internal](/docs/server/configuration#http_serverinternal_tls) HTTP endpoints. Previously, it was only possible to disable TLS for internal endpoints while keeping TLS for external ones.
 * Added TLS support for PostgreSQL clients, including support for asynchronous consumers from PostgreSQL outbox tables, database connections, and PostgreSQL-based push notification queue clients.
 * The ability to configure custom TLS settings for the proxy HTTP client.
 * A new `message_size_limit` option for WebTransport, which effectively limits the maximum size of individual messages sent through a WebTransport connection.
@@ -462,7 +462,7 @@ Moreover, the metrics mentioned above, including channel namespace resolution an
 
 The next improvement for Centrifugo PRO observability is integration with [Sentry](https://sentry.io/).
 
-With just [a couple of lines in the configuration]((/docs/pro/observability_enhancements#sentry-integration)), you can enable this feature:
+With just [a couple of lines in the configuration](/docs/pro/observability_enhancements#sentry-integration), you can enable this feature:
 
 ```json
 {

docs/faq/index.md

@@ -13,9 +13,9 @@ When connecting to Centrifugo client must authenticate using one of the supporte
 
 * [JWT authentication](../server/authentication.md)
 * [Connect proxy](../server/proxy.md#connect-proxy) authentication
-* Using proxy to set [user authentication header](../server/configuration.md#client_user_id_http_header)
+* Using proxy to set [user authentication header](../server/configuration.md#clientuser_id_http_header)
 
-You can also [configure access without token](../server/configuration.md#allow_anonymous_connect_without_token) – in this case Centrifugo will consider a connection without provided token anonymous. Or, if you just want to quickly experiment with Centrifugo during development, it's possible to turn on [client_insecure](../server/configuration.md#insecure-client-connection) option – but it **should never be used in production** since disables most of security checks.
+You can also [configure access without token](../server/configuration.md#clientallow_anonymous_connect_without_token) – in this case Centrifugo will consider a connection without provided token anonymous. Or, if you just want to quickly experiment with Centrifugo during development, it's possible to turn on [client.insecure](../server/configuration.md#clientinsecure) option – but it **should never be used in production** since disables most of security checks.
 
 Another possible reason of first time connection problems - not properly configured [allowed_origins](../server/configuration.md#clientallowed_origins). Centrifugo server logs should also clearly indicate such issues on INFO level.
 
@@ -147,7 +147,7 @@ It's possible to publish messages into channels directly from a client (when `pu
 We suggest using one of the available approaches:
 
 * When a user generates an event it must be first delivered to your app backend using a convenient way (for example AJAX POST request for a web application), processed on the backend (validated, saved into the main application database), and then published to Centrifugo using Centrifugo HTTP or GRPC API.
-* Utilize the [RPC proxy feature](../server/proxy.md#rpc-proxy) – in this case, you can call RPC over Centrifugo WebSocket which will be translated to an HTTP request to your backend. After receiving this request on the backend you can publish a message to Centrifugo server API. This way you can utilize WebSocket transport between the client and your server in a bidirectional way. HTTP traffic will be concentrated inside your private network.
+* Utilize the [RPC proxy feature](../server/proxy.md#client-rpc-proxy) – in this case, you can call RPC over Centrifugo WebSocket which will be translated to an HTTP request to your backend. After receiving this request on the backend you can publish a message to Centrifugo server API. This way you can utilize WebSocket transport between the client and your server in a bidirectional way. HTTP traffic will be concentrated inside your private network.
 * Utilize the [publish proxy feature](../server/proxy.md#publish-proxy) – in this case client can call publish on the frontend, this publication request will be transformed into HTTP or GRPC call to the application backend. If your backend allows publishing - Centrifugo will pass the payload to the channel (i.e. will publish message to the channel itself). 
 
 Sometimes publishing from a client directly into a channel (without any backend involved) can be useful though - for personal projects, for demonstrations (like we do in our [examples](https://github.com/centrifugal/examples)) or if you trust your users and want to build an application without backend. In all cases when you don't need any message control on your backend.
@@ -156,8 +156,8 @@ Sometimes publishing from a client directly into a channel (without any backend
 
 There are several ways to achieve it:
 
-* use a private channel (starting with `$`) - every time a user subscribes to it your backend should provide a sign to confirm that subscription request. Read more in [channels chapter](../server/channels.md#private-channel-prefix)
-* next is [user limited channels](../server/channels.md#user-channel-boundary) (with `#`) - you can create a channel with a name like `dialog#42,567` to limit subscribers only to the user with id `42` and user with ID `567`, this does not fit well for channels with many or dynamic possible subscribers
+* use a private channel (starting with `$`) - every time a user subscribes to it your backend should provide a sign to confirm that subscription request. Read more in [channels chapter](../server/channels.md#private-channel-prefix-)
+* next is [user limited channels](../server/channels.md#user-channel-boundary-) (with `#`) - you can create a channel with a name like `dialog#42,567` to limit subscribers only to the user with id `42` and user with ID `567`, this does not fit well for channels with many or dynamic possible subscribers
 * you can use subscribe proxy feature to validate subscriptions, see [chapter about proxy](../server/proxy.md)
 * finally, you can create a hard-to-guess channel name (based on some secret key and user IDs or just generate and save this long unique name into your main app database) so other users won't know this channel to subscribe on it. This is the simplest but not the safest way - but can be reasonable to consider in many situations
 

docs/getting-started/design.md

@@ -27,7 +27,7 @@ If the original source of events is your app backend (without any user involveme
 
 So the backend publishes data to channels and if there are active subscribers – events are delivered. If there are no active subscribers then events are dropped by Centrifugo (or, in case of using history features in channels, events may be temporarily kept in the Centrifugo history stream).
 
-It's also possible to utilize Centrifugo's bidirectional connection for sending requests to the backend. To achieve this, Centrifugo provides [event proxy features](../server/proxy.md). It's possible to send RPC (with a custom request-response) requests from the client to Centrifugo and the request will then be proxied to the application backend (see [RPC proxy](../server/proxy.md#rpc-proxy)). Moreover, the proxy provides a way to utilize the bidirectional connection for publishing into channels (using [publish proxy](../server/proxy.md#publish-proxy)). But again – in most real scenarios, your backend must validate the publication attempt, so the scheme will look like this:
+It's also possible to utilize Centrifugo's bidirectional connection for sending requests to the backend. To achieve this, Centrifugo provides [event proxy features](../server/proxy.md). It's possible to send RPC (with a custom request-response) requests from the client to Centrifugo and the request will then be proxied to the application backend (see [RPC proxy](../server/proxy.md#client-rpc-proxy)). Moreover, the proxy provides a way to utilize the bidirectional connection for publishing into channels (using [publish proxy](../server/proxy.md#publish-proxy)). But again – in most real scenarios, your backend must validate the publication attempt, so the scheme will look like this:
 
 ![client generates content](/img/design_1.png)
 

docs/getting-started/integration.md

@@ -35,15 +35,15 @@ Create a basic configuration file with `token_hmac_secret_key` (or `token_rsa_pu
 
 – which will generate `config.json` file for you with a minimal set of fields to start from.
 
-Properly configure [allowed_origins](../server/configuration.md#allowed_origins) option.
+Properly configure [allowed_origins](../server/configuration.md#clientallowed_origins) option.
 
 ## 2. Configure your backend
 
 In the configuration file **of your application backend**, register several variables: the Centrifugo token secret (if you decided to stick with JWT authentication) and the Centrifugo API key you set in the previous step, as well as the Centrifugo API endpoint address. By default, the API address is `http://localhost:8000/api`. You **must never reveal the token secret and API key to your users**.
 
 ## 3. Connect to Centrifugo
 
-Now your users can start connecting to Centrifugo. You should get a client library (see [the list of available client SDKs](../transports/client_sdk.md)) for your application frontend. Every library has a method to connect to Centrifugo. See information about Centrifugo connection endpoints [here](../server/configuration.md#endpoint-configuration).
+Now your users can start connecting to Centrifugo. You should get a client library (see [the list of available client SDKs](../transports/client_sdk.md)) for your application frontend. Every library has a method to connect to Centrifugo. See information about Centrifugo connection endpoints [here](../server/configuration.md#endpoint-management).
 
 Every client should provide a connection token (JWT) upon connecting. You must generate this token on your backend side using the Centrifugo secret key you set in the backend configuration (note that in the case of RSA tokens, you are generating JWT with a private key). See how to generate this JWT [in the special chapter](../server/authentication.md).
 

docs/getting-started/quickstart.md

@@ -132,7 +132,7 @@ That's because we have not set `allowed_origins` in the configuration (it's empt
   },
 ```
 
-Allowed origins is a security option for request originating from web browsers – see [more details](../server/configuration.md#allowed_origins) in server configuration docs.
+Allowed origins is a security option for request originating from web browsers – see [more details](../server/configuration.md#clientallowed_origins) in server configuration docs.
 
 **Restart Centrifugo** after modifying `allowed_origins` in a configuration file.
 

docs/server/channels.md

@@ -433,53 +433,61 @@ Centrifugo uses Go language [regexp](https://pkg.go.dev/regexp) package for regu
 
 `allowed_delta_types` (array of strings, the only allowed value now is `fossil`) - provide an array of allowed delta compression types in the namespace. If not specified – client won't be able to negotiate delta compression in channels.
 
-### proxy_subscribe
+### subscribe_proxy_enabled
 
-`proxy_subscribe` (boolean, default `false`) – turns on subscribe proxy, more info in [proxy chapter](proxy.md)
+`subscribe_proxy_enabled` (boolean, default `false`) – turns on subscribe proxy, more info in [proxy chapter](proxy.md)
 
-### proxy_publish
+### subscribe_proxy_name
 
-`proxy_publish` (boolean, default `false`) – turns on publish proxy, more info in [proxy chapter](proxy.md)
+`subscribe_proxy_name` (string, default `""`) – allows setting custom subscribe proxy to use by name. More info in [proxy chapter](proxy.md).
 
-### proxy_sub_refresh
+### publish_proxy_enabled
 
-`proxy_sub_refresh` (boolean, default `false`) – turns on sub refresh proxy, more info in [proxy chapter](proxy.md)
+`publish_proxy_enabled` (boolean, default `false`) – turns on publish proxy, more info in [proxy chapter](proxy.md).
 
-### proxy_subscribe_stream
+### publish_proxy_name
 
-`proxy_subscribe_stream` (boolean, default `false`) - turns on subscribe stream proxy, see [subscription streams](./proxy_streams.md)
+`publish_proxy_name` (string, default `""`) – allows setting custom publish proxy to use by name. More info in [proxy chapter](proxy.md).
 
-### subscribe_proxy_name
+### sub_refresh_proxy_enabled
 
-`subscribe_proxy_name` (string, default `""`) – turns on subscribe proxy when [granular proxy mode](proxy.md#granular-proxy-mode) is used. Note that `proxy_subscribe` option defined above is ignored in granular proxy mode.
+`sub_refresh_proxy_enabled` (boolean, default `false`) – turns on sub refresh proxy, more info in [proxy chapter](proxy.md).
 
-### publish_proxy_name
+### sub_refresh_proxy_name
 
-`publish_proxy_name` (string, default `""`) – turns on publish proxy when [granular proxy mode](proxy.md#granular-proxy-mode) is used. Note that `proxy_publish` option defined above is ignored in granular proxy mode.
+`sub_refresh_proxy_name` (string, default `""`) – allows setting custom sub refresh proxy to use by name. More info in [proxy chapter](proxy.md).
 
-### sub_refresh_proxy_name
+### subscribe_stream_proxy_enabled
 
-`sub_refresh_proxy_name` (string, default `""`) – turns on sub refresh proxy when [granular proxy mode](proxy.md#granular-proxy-mode) is used. Note that `proxy_sub_refresh` option defined above is ignored in granular proxy mode.
+`subscribe_stream_proxy_enabled` (boolean, default `false`) - turns on subscribe stream proxy, see [subscription streams](./proxy_streams.md).
 
 ### subscribe_stream_proxy_name
 
-`subscribe_stream_proxy_name` (string, default `""`) – turns on subscribe stream proxy when [granular proxy mode](./proxy_streams.md#granular-proxy-mode) is used. Note that `proxy_subscribe_stream` option defined above is ignored in granular proxy mode.
+`subscribe_stream_proxy_name` (string, default `""`) – allows setting custom subscribe stream proxy to use by name. See [subscription streams](./proxy_streams.md).
+
+### subscribe_stream_proxy_bidirectional
+
+`subscribe_stream_proxy_bidirectional` (boolean, default `false`) – allows using bidirectional subscribe stream. See [subscription streams](./proxy_streams.md).
+
+### cache_empty_proxy_enabled
+
+`cache_empty_proxy_enabled` (boolean, default `false`, Centrifugo PRO only) – turns on [cache empty proxy](../pro/channel_cache_empty.md).
 
 ### cache_empty_proxy_name
 
-`cache_empty_proxy_name` (string, default `""`, Centrifugo PRO only) – turns on [cache empty proxy](../pro/channel_cache_empty.md) when [granular proxy mode](./proxy_streams.md#granular-proxy-mode) is used. Note that `proxy_cache_empty` option is ignored in granular proxy mode.
+`cache_empty_proxy_name` (string, default `""`, Centrifugo PRO only) – allows setting custom cache empty proxy to use by name.
 
-### proxy_cache_empty
+### state_proxy_enabled
 
-`proxy_cache_empty` (boolean, default `false`, Centrifugo PRO only) - turns on cache empty proxy, see [more details](../pro/channel_cache_empty.md) in Centrifugo PRO docs.
+`state_proxy_enabled` (boolean, default `false`, Centrifugo PRO only) - allows enabling [channel state proxy](../pro/channel_events.md)
 
-### shared_position_sync
+### state_events
 
-`shared_position_sync` (boolean, default `false`, Centrifugo PRO only) - can help reducing the number of position synchronization requests from Centrifugo to Broker's history API, see [more details](../pro/scalability.md#shared-position-sync) in Centrifugo PRO docs.
+`state_events` (array of strings, empty by default, Centrifugo PRO only) - can help configuring notifications about channel's `occupied` and `vacated` state. See [more details](../pro/channel_events.md) in Centrifugo PRO docs.
 
-### channel_state_events
+### shared_position_sync
 
-`channel_state_events` (array of strings, empty by default, Centrifugo PRO only) - can help configuring notifications about channel's `occupied` and `vacated` state. See [more details](../pro/channel_events.md) in Centrifugo PRO docs.
+`shared_position_sync` (boolean, default `false`, Centrifugo PRO only) - can help reducing the number of position synchronization requests from Centrifugo to Broker's history API, see [more details](../pro/scalability.md#shared-position-sync) in Centrifugo PRO docs.
 
 ### subscribe_cel
 

docs/server/configuration.md

@@ -943,7 +943,7 @@ http://localhost:8000/connection/uni_websocket
 http://localhost:8000/api
 ```
 
-By default, all endpoints work on port `8000`. This can be changed with [port](#port) option:
+By default, all endpoints work on port `8000`. This can be changed with [port](#http_serverport) option:
 
 ```json title="config.json"
 {

docs/server/delta_compression.md

@@ -78,7 +78,7 @@ If all conditions met – subscriber will negotiate compression with a server. I
 If subscriber successfully negotiated delta compression with Centrifugo, it will start receiving deltas for publications marked with delta flag by the publisher. It's possible to mark channel publications to use delta compression upon broadcasting to subscribers in the following ways:
 
 * enable it for all publications in the channel namespace by setting a boolean channel option [delta_publish](./channels.md#delta_publish)
-* `delta` flag may be set on a per call basis (in publish or broadcast server APIs). For example, see `delta` field in [publish request](./server_api.md#publish-request) description.
+* `delta` flag may be set on a per call basis (in publish or broadcast server APIs). For example, see `delta` field in [publish request](./server_api.md#publishrequest) description.
 
 For example, this means that to automatically use delta calculation for all publications in the namespace the configuration example above evolves to:
 

docs/server/proxy.md

@@ -253,7 +253,7 @@ Above, we already gave some examples on how to enable connect proxy, let's re-it
 
 :::danger
 
-Make sure you properly configured [allowed_origins](configuration.md#allowed_origins) Centrifugo option or check request origin on your backend side upon receiving connect request from Centrifugo. Otherwise, your site can be vulnerable to CSRF attacks if you are using WebSocket transport for client connections.
+Make sure you properly configured [allowed_origins](configuration.md#clientallowed_origins) Centrifugo option or check request origin on your backend side upon receiving connect request from Centrifugo. Otherwise, your site can be vulnerable to CSRF attacks if you are using WebSocket transport for client connections.
 
 :::
 

docs/server/server_subs.md

@@ -32,7 +32,7 @@ I.e. listen for publications without any usage of subscription objects. You can
 
 :::tip
 
-The same [best practices](../faq/index.md#what-about-best-practices-with-amount-of-channels) of working with channels and client-side subscriptions equally applicable to server-side subscription. 
+The same [best practices](../faq/index.md#what-about-best-practices-with-the-number-of-channels) of working with channels and client-side subscriptions equally applicable to server-side subscription. 
 
 :::