Repository navigation
fix(admin): preserve HTTPS for upstream Swagger documents - #7895
cloudbase-ai wants to merge 2 commits into
Conversation
Signed-off-by: cloudbase-ai <[email protected]>
Aias00
left a comment
There was a problem hiding this comment.
Approving. The transport scheme was indeed lost twice — once by split(":") in the two LoadServiceDocEntryImpl conversion paths, then again by the hardcoded scheme("http") in PullSwaggerDocServiceImpl and the hardcoded "http://" protocol in DocManagerImpl#buildExtJson.
What I verified:
UriUtils.appendSchemeonly prepends when the url does not already start withhttp:///https://, so a discovery entry that already carries a scheme keeps it andgetProtocol()is correctly ignored in that case.UriUtils.getActualPortreturns 443 forhttps/wssand 80 forhttp/wswhen the port is absent, which is what makeshttps://example.comresolve tohttps://example.com:443rather thanhttps://example.com:80.URI.getHost()keeps the brackets on IPv6 literals, sohttps://[::1]:8443round-trips throughUriComponentsBuilder.host(...)correctly. The previoussplit(":")produced[as the host, so this is a fix rather than a behaviour change to preserve.SwaggerUpstreamProtocolTestswaps theOkHttpClientinside the sharedHttpUtilsand asserts the recorded request URL, so it proves the URL that actually goes over the wire for both the startup scan and the discovery callback, acrosshttps://, barehttps,http://, empty, and IPv6 forms. That is the right seam to assert at.
Non-blocking observations:
buildExtJsonnow writeshttps://into the selector'sprotocolext for HTTPS upstreams. That is the point of the change, but it also means the gateway will start using TLS for upstreams that previously received plaintext requests on anhttps://-advertised discovery entry (a common shape behind a TLS-terminating sidecar or service mesh). Existing rows keep their oldext_jsonuntil the next scan rewrites them, so this needs a line in the release/upgrade notes rather than only a code comment.getScheme()returns the raw field.buildExtJsonconcatenates it unconditionally, so anullscheme would emit"protocol": "null://". The field initialiser covers the normal path, butUpstreamInstancealso looks like a DTO that can be populated fromext_json, soStringUtils.defaultIfBlank(scheme, "http")in the getter would make it impossible to produce that string.URI.create(...)throws on inputs the oldsplit(":")silently tolerated (example.com:8080:extra, stray spaces, a scheme other than http/https). Both call sites are inside a singletryaround the whole stream, so one malformed upstream still discards every instance for that selector. The change widens the set of inputs that can trigger that. A per-item try/catch inside themap(log and skip) would keep one bad row from hiding the healthy ones.- Adding
schemetoequals/hashCodechanges instance identity:http://host:8443andhttps://host:8443used to collapse into one entry and now do not. That is correct, but it also means every HTTPS upstream re-registers its doc metadata once after this lands. Worth mentioning in the PR description so it is not mistaken for a regression. SwaggerUpstreamProtocolTestmutates the staticPullSwaggerDocServiceImpl.HTTP_UTILSsingleton and restores it infinally. That is safe today because admin tests are not parallel, but it is a global write from a test. A constructor-injectedHttpUtils(or a package-private setter) would remove the landmine and make the test independent of reflection on a private static field.- The
@CsvSourcerows duplicate the same seven cases for the scan and the event path. If a case is added later it has to be added twice; a single source feeding both entry points, or a@MethodSource, would keep them in lockstep.
|
That test drives embedded ZooKeeper registration/discovery sync through Could you please push an empty commit (or re-run the failed job once the run finishes) so |
Signed-off-by: cloudbase-ai <[email protected]>
|
Follow-up on my earlier note: the failure has changed to the shared
The same two cases are red on every other PR that touches this module right now, so this is the shared e2e case rather than your change. Could you keep this rebased and re-run once the http e2e case is fixed upstream? Nothing else blocks my approval. |
|
/retest |
|
@cloudbase-ai This PR is approved, but 2 checks are red: I inspected these lanes today and they fail for infrastructure reasons rather than on the diff — the Please rebase onto |
|
Hi @cloudbase-ai, this PR is already approved, but it currently cannot be merged. Here is the blocker and what is needed: Blocker What we need Once the branch is up to date and CI is green, we will squash-merge it. Thanks! |
|
Root cause found for the The job fails on: I traced this across three unrelated PRs (#7917, #7895, #7888) and all three fail on exactly the same two assertions, so it is not specific to your change. It is already fixed on master. The same job passes on newer heads:
Your branch is behind master (this PR: 58 commits), which is why it still carries the broken cache code. What to do: rebase onto current master and let CI re-run. That should clear this job without touching your diff. If it still fails after the rebase, the regression is genuinely yours and I will dig in again. Additional note for this PR: the |
Fixes #7894.
An upstream configured as
https://with addressexample.com:8443previously caused automatic Swagger loading to requesthttp://example.com:8443/project/v3/api-docs. Preserve the transport scheme from discovery through the internal UpstreamInstance and document request, and use port 443 when HTTPS has no explicit port. Both startup scans and discovery callbacks use URI parsing instead of colon splitting. Existing callers retain HTTP by default.Include the scheme in instance equality/hashCode and generated API document metadata. Manual Swagger import also sets the scheme on its virtual instance so imported HTTPS documents retain consistent metadata. This does not change its fetch or URL policy.
Validation on Java 17 with the Maven wrapper:
://, bracketed IPv6, document metadata, virtual import instances, equality and existing refresh/lock behavior. Request-path tests run real loader, pull service and HttpUtils code with an OkHttp application interceptor; they do not contact external hosts../mvnw -B -ntp -pl shenyu-admin -am test apache-rat:check \ -DskipRemoteResources=true -Djacoco.skip=true -Dmaven.javadoc.skip=truePR #6456 also touches address parsing in LoadServiceDocEntryImpl as part of general IPv6 support; its changes will need reconciliation with the document-loader URI parsing here. This fix is separate from the manual-import DNS/port policy in #7868 and does not claim to reproduce #6362. Docker gateway E2E and live external HTTPS backends were not exercised for this Admin document-loading change.