This is an automated email from the ASF dual-hosted git repository.
fcsaky pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/flink-connector-http.git
The following commit(s) were added to refs/heads/main by this push:
new e1988a7 [FLINK-38749] Document retry code defaults
e1988a7 is described below
commit e1988a7043e9324ba72b5271225869898e15b7d9
Author: David Radley <[email protected]>
AuthorDate: Fri Nov 28 16:40:08 2025 +0000
[FLINK-38749] Document retry code defaults
---
docs/content.zh/docs/connectors/table/http.md | 10 +++++-----
docs/content/docs/connectors/table/http.md | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/docs/content.zh/docs/connectors/table/http.md
b/docs/content.zh/docs/connectors/table/http.md
index 2fd62b8..e73ada3 100644
--- a/docs/content.zh/docs/connectors/table/http.md
+++ b/docs/content.zh/docs/connectors/table/http.md
@@ -82,7 +82,7 @@ The Flink connector does have some changes that you need to
be aware of if you a
* Existing java applications will need to be recompiled to pick up the new
flink package names.
* Existing application and SQL need to be amended to use the new connector
option names. The new option names do not have
-the _com.getindata.http_ prefix, the prefix is now _http_ prefix.
+the _com.getindata.http_ prefix, the prefix is now _http_.
## Working with HTTP lookup source tables
@@ -185,9 +185,9 @@ Note the options with the prefix _http_ are the HTTP
connector specific options,
| http.source.lookup.use-raw-authorization-header |
optional | If set to `'true'`, uses the raw value set for the `Authorization`
header, without transformation for Basic Authentication (base64, addition of
"Basic " prefix). If not specified, defaults to `'false'`.
[...]
| http.source.lookup.request-callback |
optional | Specify which `HttpLookupPostRequestCallback` implementation to use.
By default, it is set to `slf4j-lookup-logger` corresponding to
`Slf4jHttpLookupPostRequestCallback`.
[...]
| http.source.lookup.connection.timeout |
optional | Source table connection timeout. Default - no value.
[...]
-| http.source.lookup.success-codes |
optional | Comma separated http codes considered as success response. Use
[1-5]XX for groups and '!' character for excluding.
[...]
-| http.source.lookup.retry-codes |
optional | Comma separated http codes considered as transient errors. Use
[1-5]XX for groups and '!' character for excluding.
[...]
-| http.source.lookup.ignored-response-codes |
optional | Comma separated http codes. Content for these responses will be
ignored. Use [1-5]XX for groups and '!' character for excluding. Ignored
responses togater with `http.source.lookup.success-codes` are considered as
successful.
[...]
+| http.source.lookup.success-codes |
optional | Comma separated http codes considered as success response. Use
[1-5]XX for groups and '!' character for excluding. The default is 2XX.
[...]
+| http.source.lookup.retry-codes |
optional | Comma separated http codes considered as transient errors. Use
[1-5]XX for groups and '!' character for excluding. The default is 500,503,504.
[...]
+| http.source.lookup.ignored-response-codes |
optional | Comma separated http codes. Content for these responses will be
ignored. Use [1-5]XX for groups and '!' character for excluding. Ignored
responses together with `http.source.lookup.success-codes` are considered as
successful.
[...]
| http.source.lookup.retry-strategy.type |
optional | Auto retry strategy type: fixed-delay (default) or
exponential-delay.
[...]
| http.source.lookup.retry-strategy.fixed-delay.delay |
optional | Fixed-delay interval between retries. Default 1 second. Use
with`lookup.max-retries` parameter.
[...]
| http.source.lookup.retry-strategy.exponential-delay.initial-backoff |
optional | Exponential-delay initial delay. Default 1 second.
[...]
@@ -305,7 +305,7 @@ Lookup source handles auto-retries for two scenarios:
2. The response contains a HTTP error code that indicates a retriable error.
These codes are defined in the table configuration (see
`http.source.lookup.retry-codes`).
Retries are executed silently, without restarting the job.
-Notice that HTTP codes are categorized into into 3 groups:
+Notice that HTTP codes are categorized into 3 groups:
- successful responses - response is returned immediately for further
processing
- temporary errors - request will be retried up to the retry limit
- error responses - unexpected responses are not retried. Any HTTP error code
which is not configured as successful or temporary error is treated as an
unretriable error.
diff --git a/docs/content/docs/connectors/table/http.md
b/docs/content/docs/connectors/table/http.md
index 2410a11..a2cc233 100644
--- a/docs/content/docs/connectors/table/http.md
+++ b/docs/content/docs/connectors/table/http.md
@@ -82,7 +82,7 @@ The Flink connector does have some changes that you need to
be aware of if you a
* Existing java applications will need to be recompiled to pick up the new
flink package names.
* Existing application and SQL need to be amended to use the new connector
option names. The new option names do not have
-the _com.getindata.http_ prefix, the prefix is now _http_ prefix.
+the _com.getindata.http_ prefix, the prefix is now _http_.
## Working with HTTP lookup source tables
@@ -185,9 +185,9 @@ Note the options with the prefix _http_ are the HTTP
connector specific options,
| http.source.lookup.request-callback |
optional | Specify which `HttpLookupPostRequestCallback` implementation to use.
By default, it is set to `slf4j-lookup-logger` corresponding to
`Slf4jHttpLookupPostRequestCallback`.
[...]
| http.source.lookup.connection.timeout |
optional | Source table connection timeout. Default - no value.
[...]
| http.source.lookup.http-version |
optional | Version of HTTP to use for lookup http requests. The valid values
are HTTP_1_1 and HTTP_2, which specify HTTP 1.1 or 2 respectively. This option
may be required as HTTP_1_1, if the endpoint is HTTP 1.1, because some http 1.1
endpoints reject HTTP Version 2 calls, with 'Invalid HTTP request received' and
'HTTP/2 upgrade not supported'.
[...]
-| http.source.lookup.success-codes |
optional | Comma separated http codes considered as success response. Use
[1-5]XX for groups and '!' character for excluding.
[...]
-| http.source.lookup.retry-codes |
optional | Comma separated http codes considered as transient errors. Use
[1-5]XX for groups and '!' character for excluding.
[...]
-| http.source.lookup.ignored-response-codes |
optional | Comma separated http codes. Content for these responses will be
ignored. Use [1-5]XX for groups and '!' character for excluding. Ignored
responses togater with `http.source.lookup.success-codes` are considered as
successful.
[...]
+| http.source.lookup.success-codes |
optional | Comma separated http codes considered as success response. Use
[1-5]XX for groups and '!' character for excluding. The default is 2XX.
[...]
+| http.source.lookup.retry-codes |
optional | Comma separated http codes considered as transient errors. Use
[1-5]XX for groups and '!' character for excluding. The default is 500,503,504.
[...]
+| http.source.lookup.ignored-response-codes |
optional | Comma separated http codes. Content for these responses will be
ignored. Use [1-5]XX for groups and '!' character for excluding. Ignored
responses together with `http.source.lookup.success-codes` are considered as
successful.
[...]
| http.source.lookup.retry-strategy.type |
optional | Auto retry strategy type: fixed-delay (default) or
exponential-delay.
[...]
| http.source.lookup.retry-strategy.fixed-delay.delay |
optional | Fixed-delay interval between retries. Default 1 second. Use
with`lookup.max-retries` parameter.
[...]
| http.source.lookup.retry-strategy.exponential-delay.initial-backoff |
optional | Exponential-delay initial delay. Default 1 second.
[...]
@@ -305,7 +305,7 @@ Lookup source handles auto-retries for two scenarios:
2. The response contains a HTTP error code that indicates a retriable error.
These codes are defined in the table configuration (see
`http.source.lookup.retry-codes`).
Retries are executed silently, without restarting the job.
-Notice that HTTP codes are categorized into into 3 groups:
+Notice that HTTP codes are categorized into 3 groups:
- successful responses - response is returned immediately for further
processing
- temporary errors - request will be retried up to the retry limit
- error responses - unexpected responses are not retried. Any HTTP error code
which is not configured as successful or temporary error is treated as an
unretriable error.