zmuxuny opened a new issue, #6028: URL: https://github.com/apache/rocketmq-dashboard/issues/6028
### Before Creating the Enhancement Request - [x] I have confirmed this is an enhancement rather than a bug or a new feature. - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and believe this is not a duplicate. ### Summary ## Tracking continuation (2026-10-10) This replaces #5398, which was automatically closed by github-actions[bot] for inactivity on 2026-10-10. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. Existing PR #5530 by another contributor already proposes the documentation and shared golden-vector work for this issue. It remains open and unmerged. The maintainer requested corrections to test naming, unsupported constant-time claims, algorithm-token documentation and query-string vector coverage. This replacement tracks that existing PR and the outstanding compatibility-policy discussion; it does not propose a competing PR or treat the draft policy as approved. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5398. Could we document the rmqctl/Studio request-signing contract and agree how future revisions should evolve? ### Motivation The Go client and Java server implement the same signing scheme. #4310 and #4606 show that changes require coordinated updates. A concise contract would help operators plan upgrades and help other clients stay compatible. ### Describe the Solution You'd Like Agree a short specification covering: - Operator-facing authentication guarantees, required transport assumptions, timestamp/clock-skew rules, and expected retry behavior - The current wire format and canonicalization rules, with an explicit revision identifier for future changes - Supported client/server combinations, any compatibility window, unsupported-version behavior, and deprecation guidance - Shared golden vectors and client/server conformance tests for every supported revision Which starting point would maintainers prefer? 1. Document the existing scheme first, with no runtime change, and review later wire-format changes separately 2. Define the desired guarantees and version-negotiation/migration policy first, then coordinate a new revision across both implementations ### Describe Alternatives You've Considered Keep the contract in implementation comments and tests. That preserves today's behavior but makes compatibility expectations harder to discover. ### Additional Context Related implementation history: #4310 and #4606. Private-hostname HTTP compatibility is already discussed in #5300 / #5339 and should remain in that narrower thread. This is an interoperability/design question. No new defect is asserted here. Any implementation would follow the agreed scope and target rocketmq-studio. AI assistance was used to cross-check the public implementation history and existing discussions. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
