Skip to content

[Bug] DLFOpenApiV4Signer uses the default locale to canonicalize header names #10086

Description

@taoran92

Search before asking

  • I searched in the issues and found nothing similar.

Paimon version

master

Compute Engine

Java API / REST catalog authentication

Minimal reproduce step

  1. Create a DLFOpenApiV4Signer and generate headers using signHeaders().
  2. Fix the timestamp and nonce so the signature is deterministic.
  3. Rename the header key x-acs-signature-nonce to X-ACS-SIGNATURE-NONCE, keeping its value and all other headers unchanged.
  4. Call authorization() with the same request and credentials under Locale.US and new Locale("tr", "TR").

The resulting authorization strings differ. Under the Turkish locale, SignedHeaders contains x-acs-sıgnature-nonce instead of x-acs-signature-nonce: the uppercase ASCII I becomes a dotless ı.

The cause is this conversion in DLFOpenApiV4Signer.buildCanonicalHeaders():

String lowerKey = entry.getKey().toLowerCase();

Changing it to toLowerCase(Locale.ROOT) makes both cases produce the same authorization string.

What doesn't meet your expectations?

Canonical header names and request signatures should be independent of the JVM default locale. Changing the capitalization of an HTTP header name should not change the signature.

The default DLFAuthProvider path generates lowercase signing headers and does not trigger this issue. The issue is reproducible when the public authorization() method receives a signing-header map containing uppercase I, such as X-ACS-SIGNATURE-NONCE.

This reproduces a client-side signature inconsistency; rejection by a live DLF server has not been tested.

DLFOpenApiSigner already uses toLowerCase(Locale.ROOT). The V4 signer should apply the same locale-independent normalization.

Anything else?

Suggested fix:

  String lowerKey = entry.getKey().toLowerCase(Locale.ROOT);

Add a regression test with a fixed timestamp and nonce that verifies identical authorization strings for lowercase and mixed-case headers under US and Turkish locales. Restore the original default locale in a finally block.

This would follow up on #9770 and #9771

Are you willing to submit a PR?

  • I'm willing to submit a PR!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions