Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ngirardin opened this issue Jul 17, 2019 · 13 comments
Closed

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

ngirardin opened this issue Jul 17, 2019 · 13 comments

Comments

@ngirardin
Copy link

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
Copy link
Owner

mscdex commented Jul 17, 2019

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
Copy link
Author

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
Copy link
Owner

mscdex commented Jul 17, 2019

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
Copy link
Author

ngirardin commented Jul 17, 2019 via email

@dxinteractive
Copy link

dxinteractive commented Jul 31, 2019

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
Copy link
Owner

mscdex commented Jul 31, 2019

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
Copy link

dxinteractive commented Jul 31, 2019

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
Copy link

aprilmintacpineda commented Jun 27, 2020

not working until now.

I had to do

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

to accommodate this...

@cport1
Copy link

cport1 commented Jan 12, 2021

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

@kawerewagaba
Copy link

kawerewagaba commented Jul 14, 2021

@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.
Screenshot 2021-07-14 at 08 30 54

Screenshot 2021-07-14 at 08 27 03

Screenshot 2021-07-14 at 08 34 02

@charmander
Copy link

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

@yogeshzairfoil
Copy link

This is still an issue for me

@lambdaxyzt
Copy link

any fix ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants