WebSocket doesn't support essential binders

Right now, you can’t use binders like FromQuery, FromHeader, and FromCookie with WebSocket, as it doesn’t provide the required properties: headers, query, cookies. Therefore, for example, you can’t guard the WebSocket endpoint with some sort of authorization. That seems pretty important to me.

I investigated a bit into code and found out that both Request and Response inherit from the Message class, which implements headers. Request and Response have a different approach to handling cookies, and only the Request class handles query parameters. I did not dig deep, though.

The question is - which way is best to add support for all these binders for WebSocket?

1. Implement the same properties in this class, but this would duplicate the code. Easy to do, but probably better to avoid.
2. Find ways to extract the needed functionality into mixin classes - like HeadersMixin, QueryMixin, CookiesMixin. Inject them as needed. It will probably require porting WebSocket into Cython.
3. Anything else?

[RobertoPrevato]

I’m slightly concerned about the fact that now WebSocket inherits some methods and attributes of Message that it won’t likely need. Like files or form. Though I guess it’s the best solution that you can choose without refactoring the whole hierarchy.

I don’t think this is an issue. The initial WebSocket request is by definition GET, so it cannot have any body. It’s arguably the same with requests using methods that don’t allow bodies like GET, HEAD, OPTIONS, etc. - they still expose methods to read the content even though they cannot have any (or they could have but the server ignores it anyway). And I know developers who got confused because they tried to read the payload from requests done over GET, but most web frameworks simply ignore the payload and do nothing about it (on this topic).

Oh, now it makes more sense. I was wondering, why Application creates requests in this slightly odd way, passing some properties of the scope dictionary to incoming and then assigning the whole scope to the newly made request. I agree that it indeed could be cleaner.

That particular thing with incoming look crazy, I agree, but it’s one of the things I spent the most time on 😄 When I wrote it, I made many performance tests and verified it was resulting in better performance. It can be made cleaner if we “kill” the HTTP Client implementation in BlackSheep and modify Request/Response to work only in one direction - this is something I’ve been considering since a long time https://github.com/Neoteroi/BlackSheep/discussions/106.

[Klavionik]

By the way, it came to my mind that we also need to handle better the situation when the server wants to reject an upgrade request: in such case the HTTP response looks like any other response.

To me, it seems like right now we do exactly what the ASGI spec tells us to do.

Close - send event

Sent by the application to tell the server to close the connection. If this is sent before the socket is accepted, the server must close the connection with a HTTP 403 error code (Forbidden), and not complete the WebSocket handshake

https://asgi.readthedocs.io/en/latest/specs/www.html#close-send-event

Maybe I get you wrong and you meant some other case?