Typescript compilation fails for HttpRequest using SignatureV4 Presign Function

[peterhriser]

Checkboxes for prior research

• [X] I've gone through Developer Guide and API reference
• [X] I've checked AWS Forums and StackOverflow.
• [X] I've searched for previous similar issues and didn't find any solution.

Describe the bug

I am observing similar behavior to this issue:

https://github.com/aws/aws-sdk-js-v3/issues/4490

When trying to general a presigned URL, I am encountering a compilation error for mismatched types.

Property 'clone' is missing in type 'import("node_modules/@smithy/types/dist-types/http").HttpRequest' but required in type 'import("node_modules/@smithy/protocol-http/dist-types/httpRequest").HttpRequest'.ts(2741)

I am using the the smithy protocol-http type

....
import { HttpRequest } from "@smithy/protocol-http";

async function generatePresignedUrlForSTS(): Promise<HttpRequest> {
    const hostname = "sts.amazonaws.com";
    const protocol = "https";
    const request = {
        method: "POST",
        headers: {
            Host: hostname,
        },
        hostname: hostname,
        body: "Action=GetCallerIdentity&Version=2011-06-15",
        protocol: protocol,
        path: "/",
    } as HttpRequest;
    const signer = new SignatureV4({
        service: "sts",
        region: "us-east-1",
        credentials: defaultProvider(),
        sha256: Sha256,
    });
    return signer.presign(request, {
        expiresIn: 60,
    });
}

The error is indicated that the return type is invalid.

SDK version number

@smithy/signature-v4=^2.0.15, @aws-sdk/types=^3.451.0, @smithy/protocol-http=^3.0.9"

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

Node: 20.2.0 - Yarn: 1.22.19 - npm: 9.6.6

Reproduction Steps

Using the expected input and output type (import { HttpRequest } from "@smithy/protocol-http"; for the presign function on the SignatureV4 signer causes a compile error.

Observed Behavior

Compile/lint error

Expected Behavior

I expect the types to be the same

Possible Solution

I believe from looking through the code that the behavior is the same as the recently resolved issue and can be fixed in the same way.

Additional Information/Context

No response

[RanVaknin]

Hi @peterhriser ,

Thanks for reaching out. From reading the issue description Im not sure where the problem is? You linked to a previous thread that shows the solution which is to use HttpRequest from @aws-sdk/types instead of @smithy/protocol-http.

They have the same name but the type definitions from @smithy/protocol-http contains a copy method that the presigner does not expect.

If you follow the solution provided in the older thread, it should solve the issue.

Thanks, Ran~

[peterhriser]

@RanVaknin The solution worked but is that the expected behavior? It seemed from the documentation and the type stubs that was not the intended behavior

[RanVaknin]

Hi @peterhriser ,

Can you link the documentation you are following? Regarding the types, the presign method takes in any structure that conforms to this HttpRequest interface:

/**
 * @public
 *
 * Interface an HTTP request class. Contains
 * addressing information in addition to standard message properties.
 */
export interface HttpRequest extends HttpMessage, URI {
    method: string;
}

Whereas the one you tried using from @smithy/protocol-http is using this interface:

export interface HttpRequest extends IHttpRequest {
}
export declare class HttpRequest implements HttpMessage, URI {
    method: string;
    protocol: string;
    hostname: string;
    port?: number;
    path: string;
    query: QueryParameterBag;
    headers: HeaderBag;
    username?: string;
    password?: string;
    fragment?: string;
    body?: any;
    constructor(options: HttpRequestOptions);
    static isInstance(request: unknown): request is HttpRequest;
    clone(): HttpRequest;
}
export {};

So you get a type mismatch error because the expected type does not expect a clone() method.

If you have documentation contradicting this, let me know and we will fix that.

Thanks, Ran~

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.