Repository navigation
Accessing the Connection object聽#451
Description
Activity
Nevermind -
ThroughStreamobjects also emitcloseevents, meaning I don't require to rely on theConnectionobject.Other use case I had was to access
Connection::getRemoteAddress()for some other purpose, but the remote address is exposed into$request->getServerParams(), so that makes my proposal unrelevant, as I currently don't see other use cases.Sorry for polluting!
@bpolaszek Thanks for reporting and glad you've got this sorted out already!
This is useful input, I've just filed #452 to add some documentation to make sure the
closeevent is easier to find in the future 馃憤Regarding exposing the connection instance to access connection properties such as the socket addresses or TLS details, there's a similar discussion in #324, let's continue this discussion there 馃憤
Reacted by Beno!t POLASZEK
Hello there! 馃憢
I'm the maintainer of Freddie, a Mercure hub implementation leveraging Framework X and react/http - its job is mostly to broadcast Server-Sent Events.
Whenever a new request comes up, the request handler subscribes to a Redis channel and drops messages into the response body as soon as they come up. Problem is, whenever the connection closes, I have no means to get notified of that event, as the
Connectionobject is kept internal by react/http. On my side, this leads to redis subscribers kept subscribed, and performance degradations over time.Unsure if it would be crappy or legit, but an easy way to tackle this would be to inject the connection object inside the request, so that we could access it through something like
$serverRequest->getAttribute('connection'). That's what Symfony already does with its own Request system (prefixing attributes by an underscore to mark them internal). WDYT?