@@ -106,34 +106,10 @@ function getSignedHeaders(headers: RequestHeaders): string[] {
106106 if ( ! isObject ( headers ) ) {
107107 throw new TypeError ( 'request should be of type "object"' )
108108 }
109- // Excerpts from @lsegal - https://github.com/aws/aws-sdk-js/issues/659#issuecomment-120477258
110- //
111- // User-Agent:
112- //
113- // This is ignored from signing because signing this causes problems with generating pre-signed URLs
114- // (that are executed by other agents) or when customers pass requests through proxies, which may
115- // modify the user-agent.
116- //
117- // Content-Length:
118- //
119- // This is ignored from signing because generating a pre-signed URL should not provide a content-length
120- // constraint, specifically when vending a S3 pre-signed PUT URL. The corollary to this is that when
121- // sending regular requests (non-pre-signed), the signature contains a checksum of the body, which
122- // implicitly validates the payload length (since changing the number of bytes would change the checksum)
123- // and therefore this header is not valuable in the signature.
124- //
125- // Content-Type:
126- //
127- // Signing this header causes quite a number of problems in browser environments, where browsers
128- // like to modify and normalize the content-type header in different ways. There is more information
129- // on this in https://github.com/aws/aws-sdk-js/issues/244. Avoiding this field simplifies logic
130- // and reduces the possibility of future bugs
131- //
132- // Authorization:
133- //
134- // Is skipped for obvious reasons
135109
136- const ignoredHeaders = [ 'authorization' , 'content-length' , 'content-type' , 'user-agent' ]
110+ // https://github.com/aws/aws-sdk-js-v3/blob/86a26c6e93a79415385443cece377d4761dba770/packages/s3-request-presigner/src/presigner.ts#L80
111+
112+ const ignoredHeaders = [ 'content-type' ]
137113 return Object . keys ( headers )
138114 . filter ( ( header ) => ! ignoredHeaders . includes ( header ) )
139115 . sort ( )
0 commit comments