v3 Request: immutable by default

[leonklingele]

Feature Description

The zero-allocation by default promise to me seems like a very dangerous choice, often causing unexpected side effects (it also has happened to be before). People unaware of the issue will most likely end up exposing sensitive data (such as user passwords and email addresses) to others.

For v3, I'd make fiber a bit slower but much safer and easier to use by renaming the config option Immutable to NonImmutable and let it be false by default.

Thoughts on this?

Additional Context (optional)

No response

Code Snippet (optional)

No response

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have checked for existing issues that describe my suggestion prior to opening this one.
• I understand that improperly formatted feature requests may be closed without explanation.

[ReneWerner87]

We always want to provide the fastest result to the users by default and therefore we will leave it as it is currently

[Rmaan]

This is not about being fast but about having sensible defaults. Strings in Go are immutable so many libraries would rightfully store them somewhere that might outlive the request, this can break user's app in subtle ways.

My case was a feature flag evaluator library, it was buffering the evaluation events and send them in batch to the server. But user country was coming from a c.BodyParser(&request). And request was going down deep in the code layers. This library is a high level library, anyone that's doing BodyParser will have a bunch of allocation and reflection already in json package, they won't mind copying the whole body once per request, and anyways there's the option to go back to the dangerous variant if it's really needed.

Comparing to fasthttp library, they always return []byte that is mutable by default and typically won't be mistakenly stored somewhere without taking a copy.