I think this idea could be extended to "have a m2 channel" from where a handler could ask status (connections info, handlers metadata, etc).
With that, we could add more inteligence to handlers, allowing things like smart handlers allocation, or bandwidth throttling, etc. -- Carlo Pires 2012/9/25 Loic d'Anterroches <[email protected]> > > > On 2012-09-25 17:38, Florian Anderiasch wrote: > > On 09/25/2012 09:37 AM, Loic d'Anterroches wrote: > >> Hello, > >> > >> On 2012-09-24 23:43, Jason Miller wrote: > >>> Hmm, I'm not sure why that's superior to not just putting the data in a > >>> netstring? > >> > >> I suppose I was not clear enough. Basically, I want to be able to > >> exchange "meta" data with Mongrel2. We have this issue with the headers > >> (remote ip, etc.) when the message is coming from M2 to the handler and > >> from the handler to M2 we only have the client list and the payload. > >> What I think could be nice is to have on top of these, a tnetstring or > >> json with some extra meta data. These extra data should be in a > >> different tnetstring/json "part" to be clear that you cannot overlap > >> them with the headers from the client. This way one have the "trusted" > >> meta data coming from M2 directly and the headers + optional body of the > >> request from the client. > > > > > > Can't you just work with the old X-*** headers or am I missing the > > problem completely? > > Any client can create an x-*** header and send it to the server. How do > you know it was set by Mongrel2 or by the client? > > loïc >
