[core-http] use the original header name when returning raw headers

[jeremymeng]

so that the casing of header names is preserved in the result of rawHeaders().

Relevant issue: #8117

[jeremymeng]

/azp run js - storage-blob - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jeremymeng]

/azp run js - storage-file-share - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jeremymeng]

/azp run js - storage-file-datalake - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jeremymeng]

/azp run js - service-bus - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[deyaaeldeen]

The LRO engine assumes the retry header has lower case so perhaps we will need to explicitly lower the case there?

Also, all tests passed so I think we do not have any tests sensitive to headers casing.

[jeremymeng]

The LRO engine assumes the retry header has lower case so perhaps we will need to explicitly lower the case there?

Latest core-lro depends on core-rest-pipeline, which doesn't keep information about the original header names (I will log a separate issue for that). This PR only fixes core-http.

Core-http's rawHeaders() is impacted, thus toJson() and toString() too. We use rawHeaders() to

• initialize request:

  azure-sdk-for-js/sdk/core/core-http/src/fetchHttpClient.ts

  Line 146 in c2c723d

  headers: httpRequest.headers.rawHeaders(),

  • worked fine when I tested the setMetadata() scenario. Node-fetch sent requests with the original header names without any issue.
• set proxy options' headers:

  azure-sdk-for-js/sdk/core/core-http/src/proxyAgent.ts

  Line 29 in c2c723d

  headers: (headers && headers.rawHeaders()) || {}

  • worked fine in my limited testing with Fiddler as a proxy
• deserialize headers with headers mapper:

  azure-sdk-for-js/sdk/core/core-http/src/policies/deserializationPolicy.ts

  Lines 215 to 221 in ce466e5

  	if (responseSpec.headersMapper) {
  	parsedResponse.parsedHeaders = operationSpec.serializer.deserialize(
  	responseSpec.headersMapper,
  	parsedResponse.headers.rawHeaders(),
  	"operationRes.parsedHeaders",
  	options
  	);

  • In theory this might break if the headers mapper and the actual response have different header name casings. However, this seems unlikely?

I have not found real usage of toJson() or toString() in our repo. Customers may have used the raw headers from the response. I would still think this is fixing a buggy behavior though.

[deyaaeldeen]

@jeremymeng core-lro is core client agnostic and should work with either core-http or core-client.

[jeremymeng]

@jeremymeng core-lro is core client agnostic and should work with either core-http or core-client.

@deyaaeldeen Thanks! I see it now. Then this PR would would break it since it is calling toJson()

[jeremymeng]

The following approach may work

• update toJson() to not wrap around rawHeaders. Have it return an object with all lowercase header keys so the behavior is unchanged. Any existing consumers of toJson() will continue to work
• update rawHeaders() to use the original header keys. This would have a different behavior but I think is more correct. or
• we could update FetchHttpClient to re-assemble the original headers using HttpHeaders.headersArray() since it has the original information. However I feel fixing rawHeaders() is better.

I opened another PR 18348 to fix clone() behavior.