This will implement the feature mentioned in #10.

This will let the user configure HttpClients for a specific implementation. Everything specific to a client, say guzzle5, is in one class.

At the moment there is no validation of the special config. We just say: "The config you specify here is sent unparsed to Guzzle".

This PR is work in progress. I just want to show the progress. Please try it out and give me feedback. I believe the collector and extensions work properly. The work that is left is on the design and display of things.

Related to #26

TODO

• [x] Only show the first request in the stack by default
• [x] Show rest of the stack when you click "Show all"
• [x] Hide the body of the request by default and add a "Show body" button.
• [ ] Add nice design
• [x] Maybe put different adapters on different pages. Design it like the translation "Translated"/"Fallback"/"Not translated"

| Q | A | | --- | --- | | Bug? | no | | New Feature? | question | | Version | |

I just tested the bundle together with the knp github client. It is creating a PluginClient and adds a lot of extra plugins. I was (foolishly) expecting to see all plugin steps in the WebProfiler.

Is it some way we could make this happen?... Or is it anyway one could configure the knp GitHub client differently?

| Q | A | --------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Related tickets | fixes #121 | Documentation | n/a | License | MIT

fix #121. The issue occurs when a plugin like redirect is triggered, it's code create a new request and then calls $first($newRequest). By doing so, the data collector is completely messed up and show the new request in the stack which created the request and in a new request stack.

We have to find a way to not mess the display. My proposal is to inject in the debug stack a plugin that when called with a RequestInterface mark the beginning of a new request and when called with a ResponseInterface mark the end of the current request. If called with a RequestInterface twice without intermediary call with ResponseInterface, we could mark the beginning of a new request and also mark this new request as coming from the first one.

Current panel rendering (1.8MB png)

HttplugBundle configuration:

httplug:
    clients:
        centrale:
            config:
                timeout: 2
            factory: httplug.factory.guzzle6
            plugins:
                - App\Http\Plugin\AuthorizationPlugin
                - add_host:
                    host: 'localhost'
                - header_set:
                    headers:
                        Accept: application/json
                - httplug.plugin.error
                - httplug.plugin.logger
                - httplug.plugin.redirect
    plugins:
        logger:
            logger: monolog.logger.httplug

The triggered request was GET /api/user which redirects to /api/entities/1e24fb4a-e250-11e6-b52d-0242ac140002

To Do

• [x] Write a fix!
• [x] Write some internal documentation about profiling?
• [x] Mark profiler classes as @internal.
• [x] Fix existing unit tests.
• [x] Write new unit tests.
• [x] 2.7 compatibility.
• [x] Update CHANGELOG.md.

| Q | A | --------------- | --- | Bug fix? | no | New feature? |yes | BC breaks? | no | Deprecations? | no | Related tickets | fixes #312 | Documentation | if this is a new feature, link to pull request in https://github.com/php-http/documentation that adds relevant documentation | License | MIT

What's in this PR?

This allows you to disable the registration of the default HTTPlug client.

Why?

We are heavily using Symfony's auto wire functionality. Sometimes, developer inject HttpClient in the constructor without actually specifying the exact httplug.client.name. No error is thrown, and HTTPlug just picks the httplug.client.default service (or the first client it can find)

Checklist

• [x] Updated CHANGELOG.md to describe BC breaks / deprecations | new feature | bugfix
• [ ] Documentation pull request created

| Q | A | --------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | yes | Deprecations? | no | Related tickets | fix #338 | License | MIT

What's in this PR?

This PR contains the compatibility with php-http/curl-client v2.

Why?

Installing the bundle with the curl-client will trigger that error now :

Argument 1 passed to Http\Client\Curl\Client::__construct() must be an instance of Psr\Http\Message\ResponseFactoryInterface or null, instance of Nyholm\Psr7\Factory\HttplugFactory given, called in /vagrant/vendor/php-http/httplug-bundle/src/ClientFactory/CurlFactory.php on line 5

Checklist

• [x] Updated CHANGELOG.md to describe BC breaks / deprecations | new feature | bugfix
• [ ] Documentation pull request created (if not simply a bugfix)

To Do

• [x] Handle compatibility with curl-client v1 in parallel of v2

| Q | A | --------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Related tickets | --- | Documentation | --- | License | MIT

What's in this PR?

Update Symfony-related dependencies to allow 4.x-versions to make this bundle work in Symfony 4.0 applications. This PR requires php-http/stopwatch-plugin#4 to work.

lets collect what remains to be done and discuss here whether things must be in 1.0.0 or not. lets create issues for concrete tasks and reference them, and put them into https://github.com/php-http/HttplugBundle/milestones/1.0.0 if we think we need them.

| Q | A | | --- | --- | | Bug? | yes | | New Feature? | yes | | Version | n/a |

Our WebProfiler has just been updated with much more information and new design. But there is room for improvements. If we look at @florianpreusner's Guzzle Bundle we see some nice screenshots of how it could look like.

This PR fixes #17

httplug: 
  plugins: 
    cache:
      cache_pool: 'acme.cache'
      config: 
        respect_headers: true
    logger:
      formatter: 'acme.formatter'

This make sure that you can configure all our 9 configurable plugins. Some plugins (like RetryPlugin) has only optional configuration. They are enabled by default. They others are disabled by default.

Also, the LoggerPlugin is treated special. We inject the logger service automatically and it is enabled by default. This is done because of ease of use.

The clients found by discovery is not logged by the dev toolbar. This PR will add a new strategy that make sure we find a configured client.

Problems

We need to make sure constructor of ConfiguredClientsStrategy is executed. Because everything in the dependency injection is cached we can rely on that. A hack that will work is to register httplug.strategy as a event listener on kernel.request and console.command... Not sure if Im happy with that. Any input is welcome.

This PR is blocked by

• ~~https://github.com/php-http/discovery/pull/71~~
• ~~https://github.com/php-http/discovery/pull/66~~

| Q | A | --------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Related tickets | prepare for #317 | Documentation | - | License | MIT

What's in this PR?

Declaring final all classes that already are marked as @internal. Marking with @final all other classes that should be final. Making them final is technically a BC break, so we do that only in the next major.

| Q | A | --------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Related tickets | bundle integration of https://github.com/php-http/client-common/pull/167 | Documentation | - | License | MIT

To Do

• [ ] Finish the configuration and make tests work

| Q | A | ------------ | --- | Bug? | no | New Feature? | no | Version | BC breaking change: Next major

Classes like the factories are not final. We should go over the bundle and make everything final that is not explicitly intended to be extended. Also check for things with protected visibility and make them private where possible.

| Q | A | ------------ | --- | Bug? | no | New Feature? | yes | Version | 1.10.0

Actual Behavior

On each client we configure, we have to define the plugins we want. In case of plugin we want everywhere, we have to repeat the configuration on each of them.

Expected Behavior

The idea is to allow a common client configuration to be applied on each defined client.

With that, we will be able to define common plugin setup with ease. We can also think about it for other option like http_methods_client.

Sample:

httplug:
    default:
        http_methods_client: true
        plugins:
            - 'httplug.plugin.logger'
    clients:
        default:
            factory: 'httplug.factory.guzzle6'
            config:
                timeout: 5
        cacheable:
            factory: 'httplug.factory.guzzle6'
            plugins:
                - 'httplug.plugin.cache'
        dummy:
            factory: 'httplug.factory.guzzle6'
            http_methods_client: false
    profiling:
        captured_body_length: 1000

What do you think?

| Q | A | ------------ | --- | Bug? | yes | New Feature? | no | Version | 1.8.1

Without using cache plugin:

Now do this

            plugins:
                - 'httplug.plugin.content_length'
                - 'httplug.plugin.redirect'
+               - 'httplug.plugin.cache'

Result:

I'm aware this is because Cache plugin does not pass response over to other middlewares when cache is hit, but this is major usability restriction of Profiler. I would like to not wait for response while developing, but still see responses pulled out of Cache plugin. There should be a workaround in place