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.