dxyou0830 opened a new issue, #70425:
URL: https://github.com/apache/doris/issues/70425
## Version and scope
Reproduced on `doris-4.1.4-rc04-ad35a140c7f` (commit
`ad35a140c7fd0b842f18c23300bac581f7d04326`) with three FEs and one BE in a
clean, isolated cluster. The FEs use distinct HTTP and HTTPS ports and trusted
test certificates. All nodes have the same port configuration:
```properties
enable_https = true
http_port = 8030
https_port = 8050
```
These ports and every name below are illustrative placeholders, not
deployment details. Authentication is enabled; use an authorized test identity.
This report concerns the OSS `enable_https` path, not a claim about every TLS
provider or cloud deployment.
## Minimal reproduction
1. Start a healthy three-FE cluster and a BE, create a test database `<db>`,
and identify the master using `SHOW FRONTENDS`.
2. With a client that validates the test server certificate, send an
authenticated HTTPS request to a **non-master** FE:
```http
GET https://<non-master-fe>:8050/api/<db>/get_load_state?label=x
```
Choose `x` as a label that has never been submitted. Do not follow HTTP
redirects in the client.
3. Observe **HTTP 200 with JSON `code: 1`**. The error `data` field is
intentionally omitted; it can contain sensitive connection information and is
unnecessary to reproduce the bug.
4. Send the identical authenticated request directly to the master:
```http
GET https://<master-fe>:8050/api/<db>/get_load_state?label=x
```
Observe **HTTP 200, `code: 0`, `data: "UNKNOWN"`**. Existing synthetic
VISIBLE and ABORTED labels also succeed directly on the master but fail through
either follower in the affected version.
This is server-side forwarding; disabling client redirects does not prevent
it. A code=1 response is not evidence that the load failed or is safe to
resubmit.
## Fixed-commit source evidence
All links in this section refer to the reproduced commit:
- [GetStreamLoadState.java, lines
35–60](https://github.com/apache/doris/blob/ad35a140c7fd0b842f18c23300bac581f7d04326/fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/GetStreamLoadState.java#L35-L60):
non-master requests use `forwardToMaster`; the master reads the transaction
label state.
- [RestBaseController.java, lines
97–116](https://github.com/apache/doris/blob/ad35a140c7fd0b842f18c23300bac581f7d04326/fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/RestBaseController.java#L97-L116):
the URI inherits the incoming request scheme.
- [RestBaseController.java, lines
272–282](https://github.com/apache/doris/blob/ad35a140c7fd0b842f18c23300bac581f7d04326/fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/RestBaseController.java#L272-L282):
the destination uses `env.getMasterHttpPort()`, yielding an HTTPS URL with the
HTTP port.
- [Env.java, lines
1785–1788](https://github.com/apache/doris/blob/ad35a140c7fd0b842f18c23300bac581f7d04326/fe/fe-core/src/main/java/org/apache/doris/catalog/Env.java#L1785-L1788):
the master records `Config.http_port` in `MasterInfo`.
- [RestBaseController.java, lines
299–327](https://github.com/apache/doris/blob/ad35a140c7fd0b842f18c23300bac581f7d04326/fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/RestBaseController.java#L299-L327):
forwarding exceptions become a common-error envelope with HTTP 200.
Other endpoints share this forwarding path, including `GET
/api/show_proc?forward=true`, `GET /rest/v2/api/cluster_overview`, `POST
/api/<db>/_cancel`, colocate metadata and storage-policy/manager operations.
Their exposure is inferred from shared call sites; this reproduction only
exercises get_load_state and does not invoke administrative mutations.
## Expected behavior and possible fix
An HTTPS request arriving at a healthy follower should return the same label
state as a direct request to the master. The forwarding scheme and destination
port must match: an HTTPS target needs the master's HTTPS listener, not its
HTTP listener. For clusters with uniform configuration, deriving both from
`enable_https` and `https_port` is sufficient; heterogeneous FE ports require
advertising/synchronizing the master's effective HTTPS endpoint rather than
assuming the forwarding FE's local port. Internal TLS trust/identity validation
also needs to succeed; changing only the port is not a complete TLS validation
test.
## Existing upstream work and backport question
[PR #60921](https://github.com/apache/doris/pull/60921) is already merged.
At master commit `13f4d297a52b9aadb9a57e2736a27b5e93de20d0`,
[RestBaseController](https://github.com/apache/doris/blob/13f4d297a52b9aadb9a57e2736a27b5e93de20d0/fe/fe-core/src/main/java/org/apache/doris/httpv2/rest/RestBaseController.java#L333-L343)
uses `HttpURLUtil.buildInternalFeUrl`; [the
helper](https://github.com/apache/doris/blob/13f4d297a52b9aadb9a57e2736a27b5e93de20d0/fe/fe-core/src/main/java/org/apache/doris/common/util/HttpURLUtil.java#L81-L95)
selects `Config.https_port` when HTTPS is enabled. This is source
verification, not a runtime test of master.
The older forwarding construction remains in the inspected maintenance heads:
| Branch | Inspected commit |
|---|---|
| branch-4.0 | `8a9961723ea4be00cdf923c60759607202c7e2e7` |
| branch-4.1 | `65f59e26b2bb51edc858195f8f5b2b33eaf6c01f` |
| branch-4.1.4 | `5dbec55b399c2c4323f565bb2c6745cacb574416` |
| branch-4.2 | `726167bd85f06ba1f2089acb54a1463629341287` |
Could you confirm the intended backport/release coverage of #60921 for these
branches, and whether a follower/master regression test with different
HTTP/HTTPS ports is included? Related work:
[#64670](https://github.com/apache/doris/pull/64670), [closed-unmerged
#65212](https://github.com/apache/doris/pull/65212), and [open
#68054](https://github.com/apache/doris/pull/68054). This report supplements
the existing work rather than proposing a duplicate master implementation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
