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

Add support for removing body parser limit #493

Closed
ImRodry opened this issue Feb 26, 2023 · 8 comments
Closed

Add support for removing body parser limit #493

ImRodry opened this issue Feb 26, 2023 · 8 comments
Labels

Comments

@ImRodry
Copy link

ImRodry commented Feb 26, 2023

The body parser libraries support passing a null limit, however the types for body-parser and express don't allow this, same for the code which uses a logical OR to set the default, which would override null. You should instead use JS's default parameters and stop using such outdated code to support this, because some of us don't want set limits on the amount of data we want to receive.

@dougwilson
Copy link
Contributor

Hi @ImRodry that should be possible already. Does limit: Infinity not work?

@dougwilson
Copy link
Contributor

Ok, I just tested and limit: Infinity works. We will fix so limit: null will also work in the 2.x branch as an additional method too, but cannot in the 1.x branch as anyone currently passing in null will be at 100kb and they would suddenly have no limit if they were to do a non-semver-major upgrade and be exposed to DoS. Thank you for reporting and I hope the above helps you at least get a working no-limit in the 1.x as well 👍

@ImRodry
Copy link
Author

ImRodry commented Feb 26, 2023

Hello @dougwilson I did find the Infinity workaround but that is not ideal. Adding support for a null limit would not be a breaking change because null is an explicitly empty value, as opposed to undefined which is meant to be ignored. Furthermore users in TS are currently not allowed to set the limit to null. I believe this should be added in a minor version.

@dougwilson
Copy link
Contributor

Thank you for your perspective. Unfortunately I cannot do that due to the existing behavior and the change introducing a DoS vector to existing users, even if you believe that they are using it "incorrectly" -- it is not a risk we will expose our users to without a major version increase.

As for typescript definitions, I believe you would need to open an issue on definitely typed project, as that is where the definitions are maintained.

@expressjs expressjs locked as resolved and limited conversation to collaborators Feb 26, 2023
@expressjs expressjs unlocked this conversation Feb 26, 2023
@ImRodry
Copy link
Author

ImRodry commented Feb 26, 2023

Ah I forgot express doesn't export its own types (it really should)
I don't really understand why this has to be under a major version bump since that is not a valid use case. Why would anyone explicitly pass the limit as null when they want to use the default? Wouldn't they just be better off not passing it at all, or doing so as undefined if they need to for some bizarre reason? This should not be considered a breaking change under semver.
Also seeing as the issue for 2.0 was created in 2014, is there a set date or estimation for when it will be released or will we have to wait another 10 years?

@dougwilson
Copy link
Contributor

Ah I forgot express doesn't export its own types (it really should)

There is a meta issue for this, but the project does not have any members who are here to maintain TypeScript definitions or have knowledge of it. Until we do, the definitely typed project maintains them for us.

I don't really understand why this has to be under a major version bump since that is not a valid use case. Why would anyone explicitly pass the limit as null when they want to use the default? Wouldn't they just be better off not passing it at all, or doing so as undefined if they need to for some bizarre reason? This should not be considered a breaking change under semver.

I cannot answer why folks do strange things. It is a consequence of having a HUGE user base. We have been burned many, many times for attempting to release these types of fixes in a non-mjaor and just have to roll them back almost every time. This one would actually cause a security issue, so we definitely take the conservative line.

Also seeing as the issue for 2.0 was created in 2014, is there a set date or estimation for when it will be released or will we have to wait another 10 years?

I mean, a new 2.0 was just release a few days ago... it is actively being push though the pipes for testing to be released and it's stale at all.

I'm sorry you don't like that our API is limit: Infinity in the 1.x version and I tried to accommodate your request by adding a mark to add limit: null as an alias. Sometimes a project doesn't always have the exact API you think it should have, and I provided a plan that would actually add what you requested.

@ImRodry
Copy link
Author

ImRodry commented Feb 26, 2023

I had no idea 2.0 versions were being pushed but like I said I don't use this library directly, I use express which imports it, so it wouldn't be practical to install a version other than the one express ships with. Either way the first beta was published more than a year ago, which is why I asked when it was gonna be fully released, and most importantly when it will be added to express.
As a sidenote about the TS definitions you can always have the community help you for things like this, just like you are doing right now, just in a different repo. TS definitions really aren't hard and you already have some basis to work off of, so it shouldn't be too hard

@ImRodry
Copy link
Author

ImRodry commented Feb 26, 2023

Either way I am using the Infinity limit at the moment, it just didn't seem intentional that that works and I'd rather use null, but I understand your motives

@expressjs expressjs locked as too heated and limited conversation to collaborators Feb 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants