PDGGK commented on issue #8852: URL: https://github.com/apache/paimon/issues/8852#issuecomment-5301879002
@fwonce I've opened #9238 for this — your diagnosis and the suggested shape were both right, and it follows the `fs.oss.sld.enabled` precedent you pointed at. You had ticked "willing to submit a PR", so if you'd rather send your own, say the word and I'll close mine. One finding from writing the test that's worth recording here. My first attempt built the client with `new OSSClientBuilder().build(endpoint, "ak", "sk")` and the assertion failed because the bucket was *already* in the signed host — `ClientBuilderConfiguration extends ClientConfiguration` and sets `supportCname = false` in its constructor. So the SDK's own builder opts out of the heuristic by default; it is specifically the bare `new ClientConfiguration()` that `AliyunOSSFileSystemStore` uses (line 99) which leaves it on. That is why this only bites through the Hadoop path, and it means a test written against `OSSClientBuilder` would pass without the fix. The measured behaviour, asserting the host `OSSUtils.determineFinalEndpoint` produces — the same call `OSSRequestMessageBuilder` makes for every request: | endpoint | before | with `fs.oss.cname.enabled=false` | |---|---|---| | `oss-cn-x.inter.env99.example.com` | `oss-cn-x.inter.env99.example.com` | `my-bucket.oss-cn-x.inter.env99.example.com` | | `oss-cn-hangzhou.aliyuncs.com` | `my-bucket.oss-cn-hangzhou.aliyuncs.com` | unchanged | I don't have a private-cloud OSS deployment to point at, so if you can run the branch against yours and confirm the `SignatureDoesNotMatch` goes away, that would close the last gap. -- 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]
