search

vibe-d / vibe-http

Future vibe.d HTTP implementation
15 stars 9 forks source link

Non const req #41

Closed Alexibu closed 4 months ago

Alexibu commented 4 months ago

To access cookies from the request that started a WebSocket, the HTTPServerRequest cannot be const, because reading the cookies is not done until required.

Alexibu commented 4 months ago

Your version works for me, thanks.

Alexibu commented 4 months ago

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.

s-ludwig commented 4 months ago

Another way could be to introduce a read-only view to a request object that is not marked as const, but doesn't expose any APIs that allow mutation. But it doesn't really seem worth it to complicate the API just for that little bit of usage safety.

Alexibu commented 4 months ago

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.