detailed reporting in toolbar

[dbu]

Right now, we add the reporting at the begin of the plugin chain. This means we don't see the exact request as it was sent to the server, and we dont see whether a request is answered from cache or not, and we will miss redirects.

We could use a second plugin at the end of the chain, and correlate the requests to determine: request going to actual HTTP client (and thus to real server) / request leading to redirect / request served from cache.

See also https://github.com/php-http/HttplugBundle/pull/19/files#r49300763

Another thing is that we should identify which client was used, in the case where there is more than one client that reports requests. (follow up of #36)

[sagikazarmark]

This is something that would only make sense here, so the plugin itself could be in this repository, isn't it?

[Nyholm]

I do not think we need a new plugin class. We just need a new HistoryPlugin service and add that last in the chain.

We could maybe do something cool when displaying this.. Like a git diff to show what was changed by the plugin chain.

[sagikazarmark]

Diff sounds cool, but unsure about the usefulness in this case...but I am not against it.

Also, see php-http/httplug#105 for diff stuff

[Nyholm]

I suggest we add two collectors per client. One at the beginning of the plugin queue and one at the end. We want to do it per client because we want to show that client X sent this request and client Y sent that request.

[sagikazarmark]

Why would we need two collectors.

We want to add something to the beginning and to the end of a queue where the order matters. It sounds familiat, doesn't it? (Plugin chain)

Maybe we can somehow pass the client to the journal as well to identify the sender?

[joelwurtz]

Or it could be a PluginClientDebug whichs extends the PluginClient one to replace the plugin chain and log the total stack trace of a request (go in this plugin, then in this one, then in this client, ...)

[Nyholm]

I can't see how we could pass an identifier to the journal/history plugin to be used every second time. That's why I suggested two collectors.

I like @joelwurtz idea with a PluginClientDebug. That would make a lot of things easier to extract. Like which plugins are used with which clients. It could also be easier to inject the data collector and also a stopwatch(?).

[sagikazarmark]

I also like the idea. But keep in mind that this debug client must not have any more features than debug. I mean, the behavior should be transparent: logging should also be done in prod mode in the "ordinary" plugin client with the configured logger. (BTW: is it possible right now to configure multiple logger plugins with different loggers (channels)?)

[joelwurtz]

I think we can integrate the debug in the existing PluginClient by adding a debug options which takes a Plugin as the input (or a list of plugins) and these plugins are injected between each existent plugin

[sagikazarmark]

Will this be solved by #84?