-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
🐞 Document clearly that properties of the request ctx are invalid after the handler returns #185
Comments
Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! |
We use the same method as Fasthttp to convert strings and bytes without memory allocation, but proper use requires you to never change the original byte array, but that's a reasonable contract in many cases. I did not see many use-cases to persist values after returning from the handler, so this is an interesting topic. |
It is true that it is possible to reproduce the same behavior in Fasthttp, but in Fasthttp it is more forgivable since a) it is clearly documented and b) there is no implicit contract implied in returning a |
@yossizahn, you have a good point and we can provide an func main() {
app := fiber.New(&fiber.Settings{
Immutable: true,
})
app.Get("/:number", func(c *fiber.Ctx) {
number := c.Params("number") // immutable
go func() {
time.Sleep(1 * time.Second)
fmt.Println("number: ", number)
}()
})
app.Listen(3000)
} |
I'm closing this issue because it will be addressed in v1.8.0, feel free to re-open! |
I wish the strings returned from the context were wrapped in a new unsafestring struct so when you wrote the code you are forced to call getUnsafeString() or something so it's obvious what you're doing. That way I would pass around unsafestring into functions so I know the string is mutable! All the other go docs say strings are immutable. |
Fiber version/commit: Latest
Issue description
Not sure if this is intentional or somewhat of a bug.
Currently, many properties of the request context are returned as strings but are unsafe to persist after the handler has returned (due to unsafe conversion here).
Expected behavior
It should be possible to safely store request properties for reuse after the handler has returned.
Steps to reproduce
See code snippet. Send a few requests in quick succession, e.g.:
The second
fmt.Printf
will not output the correct value.Code snippet
The text was updated successfully, but these errors were encountered: