Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merging to release-5.6: [TT-13088] Fixed godoc for path prefix and sufix configs (#6610) #6612

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions config/config.go
Original file line number Diff line number Diff line change
Expand Up @@ -410,40 +410,40 @@ type HttpServerOptionsConfig struct {

// EnablePathPrefixMatching changes how the gateway matches incoming URL paths against routes (patterns) defined in the API definition.
// By default, the gateway uses wildcard matching. When EnablePathPrefixMatching is enabled, it switches to prefix matching. For example, a defined path such as `/json` will only match request URLs that begin with `/json`, rather than matching any URL containing `/json`.

//
// The gateway checks the request URL against several variations depending on whether path versioning is enabled:
// - Full path (listen path + version + endpoint): `/listen-path/v4/json`
// - Non-versioned full path (listen path + endpoint): `/listen-path/json`
// - Path without version (endpoint only): `/json`

//
// For patterns that start with `/`, the gateway prepends `^` before performing the check, ensuring a true prefix match.
// For patterns that start with `^`, the gateway will already perform prefix matching so EnablePathPrefixMatching will have no impact.
// This option allows for more specific and controlled routing of API requests, potentially reducing unintended matches. Note that you may need to adjust existing route definitions when enabling this option.

//
// Example:

//
// With wildcard matching, `/json` might match `/api/v1/data/json`.
// With prefix matching, `/json` would not match `/api/v1/data/json`, but would match `/json/data`.

//
// Combining EnablePathPrefixMatching with EnablePathSuffixMatching will result in exact URL matching, with `/json` being evaluated as `^/json$`.
EnablePathPrefixMatching bool `json:"enable_path_prefix_matching"`

// EnablePathSuffixMatching changes how the gateway matches incoming URL paths against routes (patterns) defined in the API definition.
// By default, the gateway uses wildcard matching. When EnablePathSuffixMatching is enabled, it switches to suffix matching. For example, a defined path such as `/json` will only match request URLs that end with `/json`, rather than matching any URL containing `/json`.

//
// The gateway checks the request URL against several variations depending on whether path versioning is enabled:
// - Full path (listen path + version + endpoint): `/listen-path/v4/json`
// - Non-versioned full path (listen path + endpoint): `/listen-path/json`
// - Path without version (endpoint only): `/json`

//
// For patterns that already end with `$`, the gateway will already perform suffix matching so EnablePathSuffixMatching will have no impact. For all other patterns, the gateway appends `$` before performing the check, ensuring a true suffix match.
// This option allows for more specific and controlled routing of API requests, potentially reducing unintended matches. Note that you may need to adjust existing route definitions when enabling this option.

//
// Example:

//
// With wildcard matching, `/json` might match `/api/v1/json/data`.
// With suffix matching, `/json` would not match `/api/v1/json/data`, but would match `/api/v1/json`.

//
// Combining EnablePathSuffixMatching with EnablePathPrefixMatching will result in exact URL matching, with `/json` being evaluated as `^/json$`.
EnablePathSuffixMatching bool `json:"enable_path_suffix_matching"`

Expand Down
Loading