Busboy is expecting the Content-Type header key to lower case

[ngirardin]

Hi guys,

I'm running into troubles when using Busboy to parse a multipart/form-data from serverless on AWS lambda.

My event.headers contains 'Content-Type': 'multipart/form-data; boundary=---------------------------30333176734664' but the lib fails with Error: Missing Content-Type' message.

It looks like the headers are not case sensitive (https://stackoverflow.com/a/5259004/534838).

Do you want me to push a PR that read the headers in a non-case sensitive way?

Best,
Nicolas

[mscdex]

The reason it is this way is that node generates headers objects with lowercased header names to normalize them. I think it would be better to just normalize event.headers first in the same way.

[ngirardin]

Hi mscdex,

Thanks for the quick reply.

This change would allow the lib to be RFC compliant and work and work out of the box with serverless / aws lambda and not be dependant on some node behavior.

Best,

[mscdex]

The reason I suggested that is because chances are you will run into the same issue with other node modules, so it would be easier to fix it one place rather than every single node module that would need such a change.

[ngirardin]

Thanks for your reply

…

On Wed, Jul 17, 2019 at 9:06 PM mscdex ***@***.***> wrote: The reason I suggested that is because chances are you will run into the same issue with other node modules, so it would be easier to fix it one place rather than every single node module that would need such a change. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#210?email_source=notifications&email_token=AAENRQBPJCJQRKS5WPLZFR3P75UUNA5CNFSM4IESZVDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GI5KQ#issuecomment-512528042>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAENRQHUZ5F6NZJB6QIB7HDP75UUNANCNFSM4IESZVDA> .

-- Nicolas Girardin

[dxinteractive]

I'd like to see this change added if possible too, because without it this library is not complying with RFC2616. One of the main reasons that the RFC exists at all is so there is a single source of information that everyone can point to and see how things should be done.

The reason I suggested that is because chances are you will run into the same issue with other node modules, so it would be easier to fix it one place rather than every single node module that would need such a change.

If other modules are also not following the RFC then I think they should fix their issues too.

It's like if you had a building without wheelchair access, and regulations say you should have wheelchair access. It's not all that fair to tell people with wheelchairs that they should carry their own ramps just because other buildings might not also have wheelchair access :P

So yeah, I'm in a wheelchair, because I'd also like to use busboy on a lambda which has mixed-case headers. I'd rather not carry a ramp (and do my own header normalisation) just to be able to use busboy.

Anyway, if anyone else hits this then here is a super quick header normalisation function you can copy paste:

headers = Object.keys(headers).reduce((newHeaders, key) => {
    newHeaders[key.toLowerCase()] = headers[key];
    return newHeaders;
}, {});

[mscdex]

If other modules are also not following the RFC then I think they should fix their issues too.

What I meant is node modules like busboy assume they're being used in conjunction with functionality provided by node core, which automatically lowercases all incoming headers to make them easily accessible no matter what casing was used by the client.

So my suggestion to emulate what node core does is to improve compatibility with any node module with much less friction and effort. As you've shown, the code needed to provide this compatibility in userland code is trivial, so it does not need to live inside all of the node modules that deal with HTTP headers, where it would only cause performance slowdowns for majority use cases.

[dxinteractive]

Ok gotcha. Yeah, it's that assumption that they're being used in conjunction with functionality provided by node core that I don't necessarily agree with, but that's fine, and you have to draw the line somewhere. Thanks!

[aprilmintacpineda]

not working until now.

I had to do

{
  ...headers,
  'content-type': headers['Content-Type']
}

to accommodate this...

[cport1]

I am getting this issue today and I definitely see content-type all lowercase.

[kawerewagaba]

@cport1 was this resolved? Running a function on gcp. Logging req.headers returns all headers lowercased, including content-type. Same is true when looking at chrome's network request headers. However, busboy still throws the Missing Content-Type error down the line.

[charmander]

@kawerewagaba What’s the code that uses Busboy – especially the call to the constructor?

[yogeshzairfoil]

This is still an issue for me

[lambdaxyzt]

any fix ?