Incosistent filter() behaviour with ESPAsyncWebServer

[theelims]

I am using the filter() callback to authenticate a Websocket connection. A short lived JWT token is supplied as a search parameter like so:

/ws/lightState?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiYWRtaW4iOnRydWV9.7j33pzYbZ-Uf_irNQxzPG7UGTpKMV-VhTPTLA1RV_oM

The first issue I encountered when porting my code from ESPAsyncWebserver was that the search parameters are not resolved on calling the filter function yet. Only on handleRequest the parameters are evaluated. This can be fixed by calling request->loadParams(); inside the filter function. However with the current way of concatenating the parameters in loadParams() it will introduce a bug with the parameters being present twice unable to evaluate properly when called the second time in handleRequest. For my use case I can ignore that bug.

The second issue I ran into was that the filter is called with every received frame again. But this time without headers or parameters. Thus my filter function would returns false and the websocket connection closes with the first received message. I found a hack around this, as the request is initialized with the defaults like an empty string for the URI or method HTTP_DELETE (=0). This is not nice and potentially opens up an attack vector for my app.

@hoeken Is this deviation from the ESPAsyncWebserver desired? If not it would be really nice if the request would be fully initialized when calling the filter function already. And received websocket frames don't need to go through that filter every time, as the connection passed the filter when it had been established.