-
Notifications
You must be signed in to change notification settings - Fork 9
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
Non const req #41
Non const req #41
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I had the same issue before and couldn't come to a fully satisfying solution at the time. But although logically this should really be const
, for practical reasons this it looks to be the best approach to just drop that.
Your version works for me, thanks. |
I suppose the D const system has forced recognition that you can't read cookies from a const request, because the way cookies are read is a mutating action, as it is done on demand, and can't be done more than once presumably. I guess the other solution is to change cookies from being a property of request, to being a factory for a new cookies object each time and allow it to be read multiple times if the user does this. |
Another way could be to introduce a read-only view to a request object that is not marked as |
I don't think anyone wants to actually mutate a request, so the cookies could be a const map. But it would be a perforrmance hit to read the cookies if no one needs them. Most likely there is only one place in a users code that wants the cookies, so we could add a readCookies(Cookies cookies) const method. That way requests can be const and you can still get the cookies by supplying your own mutable cookies. |
To access cookies from the request that started a WebSocket, the HTTPServerRequest cannot be const, because reading the cookies is not done until required.