Skip to content

Signature mismatch when using SetPreservePathSeparators(true) and AssumeRole #3484

@shurarama

Description

@shurarama

Describe the bug

When calling Aws::STS::STSClient::AssumeRole() after enabling Aws::Http::SetPreservePathSeparators(true), the SDK generates an invalid signature.

Regression Issue

  • Select this option if this issue appears to be a regression.

Expected Behavior

The request should succeed with a valid signature, as it does without SetPreservePathSeparators(true).

Current Behavior

The request fails with the following error:

SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method.

Reproduction Steps

Aws::Http::SetPreservePathSeparators(true);
Aws::STS::STSClient sts;
auto outcome = sts.AssumeRole(...); // ❌ Signature mismatch

Possible Solution

Reset the m_pathHasTrailingSlash flag in URI::SetPath() before calling AddPathSegments():

void URI::SetPath(const Aws::String& value)
{
    m_pathSegments.clear();
    m_pathHasTrailingSlash = false; // ✅ Fix: reset trailing slash
    AddPathSegments(value);
}

Additional Information/Context

This issue affects requests that do not contain an explicit URI path — for example, AssumeRole in STS or ListNamedQueries in Athena.

It only reproduces when Aws::Http::SetPreservePathSeparators(true) is enabled, which is needed for valid S3 keys that include empty path segments (e.g., "//folder//file.txt").

AWS CPP SDK version used

1.11.606

Compiler and Version used

gcc (Debian 14.2.0-19) 14.2.0

Operating System and version

Ubuntu

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugThis issue is a bug.needs-triageThis issue or PR still needs to be triaged.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions