AWS_BEARER_TOKEN_BEDROCK with empty string causes incomplete signature errors

[shixions]

Describe the bug

When AWS_BEARER_TOKEN_BEDROCK is set to an empty string (via export AWS_BEARER_TOKEN_BEDROCK=), boto3 treats it as a valid bearer token and uses it for authentication, causing "incomplete signature" errors. The empty string should be treated as if the variable is unset.

Regression Issue

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

Expected Behavior

• Empty string should be ignored
• Fall back to AWS credentials (IAM role, assume role, etc.)

Current Behavior

• boto3 uses empty bearer token in HTTP request headers
• Requests fail with incomplete signature errors
• Only unset AWS_BEARER_TOKEN_BEDROCK works (not export AWS_BEARER_TOKEN_BEDROCK=)

Reproduction Steps

export AWS_BEARER_TOKEN_BEDROCK=

python3 << EOF
import boto3
import logging
boto3.set_stream_logger('', logging.DEBUG)

client = boto3.client('bedrock-runtime', region_name='us-east-1')
# Fails with incomplete signature error
# Debug log shows BEARER_TOKEN in request headers
EOF

Possible Solution

No response

Additional Information/Context

No response

SDK version used

boto3: 1.35.69; botocore: 1.35.69

Environment details (OS name and version, etc.)

macOS

[nateprewitt]

Hi @shixions,

Was there something you'd found in documentation indicating that using an empty string would disable the feature? Most of our other AWS_* scoped environment variables treat the variable as being set when present regardless of the value. This is also inline with typical behavior *nix and Windows based systems where you're denoting the difference of an empty value and a nulled (or unset) value.

I don't think we'd consider this a bug currently, otherwise we'd be special casing the bedrock token which is likely to create further confusion. Please let us know if you believe we're missing something though.

[yuntaoL]

@nateprewitt I agree, but anyway, empty string is not a valid BEARER_TOKEN, so it will be great at least have a warning log, otherwise, without enable debug log of boto3, and check the request header in detail, it is not possible to figure out the issue.

[nateprewitt]

Sure, I think that's fair. We'd need to change the specification across all of the SDKs, so it's a little larger than just patching Boto3. That does seem like a reasonable constraint though. The RFC is pretty clear we shouldn't have an empty token in the auth header.

Let me see what we can do to make the failure mode more streamlined.