Headers cased incorrectly

[harshithkashyap]

Investigative information

Please provide the following:

• Core Tools: Azure Functions Core Tools (2.7.1948 Commit hash: 29a0626ded3ae99c4111f66763f27bb9fb564103)
• Function Runtime Version: 2.0.12888.0
• Timestamp: NA
• Function App name: NA
• Function name(s) (as appropriate): NA
• Invocation ID: NA
• Region: NA

Repro steps

Provide the steps required to reproduce the problem:

1. Create a function with httpTrigger.
2. Trigger the function using the endpoint and include a header with an empty value.
   

Expected behavior

Headers with empty values should be parsed as empty string.
The following screenshots shows the headers with empty values being correctly parsed by ngrok.

Actual behavior

Instead, the other subsequent headers are parsed for the empty header.

Known workarounds

There are no known workarounds as of now as it's difficult to predict the empty header without access to raw http request.

Related information

• Programming language used: TypeScript.

[mhoeger]

Hi @harshithkashyap, the reason why we don't pass this information is because of a serializing issue that we discovered with using proto3.

Here's the original issue: #142

And this is the fix needed: Azure/azure-functions-language-worker-protobuf#21

While this is unavailable, our recommended workaround is to access header data through context.bindingData.headers, where the same information is available)

module.exports = async function (context, req) {
  return {
    status: 200,
    body: {...context.bindingData.headers},
    headers: {
        'content-type': 'application/json',
    },
  };
}

[harshithkashyap]

@mhoeger I can now see the header under context.bindingData.headers object but it looks like the first character in the header is lowercased and the original casing is maintained for others. Eg, X-CUSTOM-HEADER becomes x-CUSTOM-HEADER. The headers should not be case sensitive and ideally be lower cased even in bindingData object.

[mhoeger]

Adding to this issue - in bindingData, it's "x-CUSTOM-HEADER". In req.headers, it's 'x-custom-header', and what we expect is "X-CUSTOM-HEADER"

[vicancy]

Any ETA to fix this?

[mhoeger]

@vicancy - Don't have a good ETA on this item. Either we patch headers to have both combinations of casing (which is a bit strange but not a breaking change) or we fix the first letter to not become lower cased (which is a breaking change for people who are relying on that).

One thing that may be helpful is that the request object by default has a "get" method that takes a header name and gets the property, regardless of casing. I think using req.get("X-CUSTOM-HEADER"); is currently the best way forward..!

[vicancy]

TBH, fixing the req.headers parser sounds the most important one to me. It is indeed unexpected behavior and is a bug.

[mhoeger]

@vicancy - sorry what do you mean? HTTP headers are expected to be case insensitive. The reason why it's case sensitive is because we expose headers as a properties of a JavaScript object (in addition to exposing it through the req.get method, which is case insensitive).

If we pushed out a fix today to preserve a header's casing to the best of our ability, current users who are looking for something like "x-CUSTOM-HEADER" would immediately be broken. I know that the casing is unexpected but I don't know what you mean by "fixing the parser sounds the most important." What is your suggestion there?

[vicancy]

I mean the original issue: "Empty Headers are parsed incorrectly" in req.headers

[mhoeger]

Update: "Empty Headers are parsed incorrectly" issue has been fixed but not headers cased incorrectly issue.

[glasser]

Just to clarify: when writing a function that uses @azure/functions and reads headers, is the correct way to read the header to use req.headers['lowercase-version-of-the-header-you-care-about']?

@mhoeger refers to req.get but I don't see that in the TypeScript definitions file.

[ejizba]

I can confirm this is still happening because of this logic. I used this to test:

curl -H "X-CUSTOM-HEADER: test" http://localhost:7071/api/HttpTrigger1

We should at least decide on best practice and make sure it's added to the TypeScript definitions. Longer term we should consider removing that extra camel case logic because it may be more trouble than it's worth.

[ejizba]

For the existing programming model, we recommend using request.get('header-name') because it is case insensitive. I have added the type for that in Azure/azure-functions-nodejs-library#10

For the new programming model, this was addressed in Azure/azure-functions-nodejs-library@efa5fb3. I've started a doc here with more information: https://aka.ms/AzFuncNodeV4