BrowserKit\Client::request() overwrites $server values

[remipIGN]

I am running some tests with phpunit. My Apache server is configured to use an alias, so to create my client I set the parameter HTTP_HOST like this :

$client = static::createClient(array(), array('HTTP_HOST' => 'localhost/myalias/app_dev.php')) ; 
$client->followRedirects() ;

Then, I do a request with absolute URL and no $server parameter :

$url = $this->getUrl('my_route', array(), UrlGeneratorInterface::ABSOLUTE_URL) ; // https://localhost/myalias/app_dev.php/myroute
$crawler = $client->request('GET', $url) ; // $server = array(), default value

• First time, the request() method is called, everything is fine. But there is a redirection, and in header the Location is set to /myalias/app_dev.php/myotherroute, URL is no more absolute (https://github.com/symfony/symfony/blob/master/src/Symfony/Component/BrowserKit/Client.php#L325).
• With followRedirects set to true, the request() method is called a second time. But this time, the parameter $server is not empty as it was the first time, but it has a key HTTP_HOST set to null.
• So when $server is merged with $this->server (here : https://github.com/symfony/symfony/blob/master/src/Symfony/Component/BrowserKit/Client.php#L288), the previous HTTP_HOST I defined with createClient() becomes null too.
• Finally, $server['HTTP_HOST'] is set to 'localhost', which was the result of extractHost()

As a consequence, I am doing a GET /myalias/app_dev.php/myotherroute on localhost, which returns 404.

I hope my explanations are not too confused... Any idea if I can fix this problem ?

By the way, I am using theses parameters to generate URLs (in parameters.yml) :

router.request_context.host: localhost
router.request_context.scheme: https
router.request_context.base_url: /myalias/app_dev.php

Why the request() method does not use these parameters too ? (maybe I'm missing something).

[stof]

localhost/myalias/app_dev.php is not a HTTP_HOST value. this is not what you would get in it. So this looks like trying to do a hack and then discovering that it does not always work

[remipIGN]

Yes, it was definitely a hack, you found me guilty ;-) (and this is actually not the first one I tried).

Usually, when I have to work with CLI and router, I use the router.request_context.* parameters (as described here : http://symfony.com/doc/2.8/cookbook/console/request_context.html), and it works really fine. But it seems the request() method does not use it, so I'm kind of lost.

Is there a good way to call request() when we have an apache alias like me ?

Thank you.

[remipIGN]

I think I'm wrong since the beginning.

My Apache server is currently down, but I can still run my tests (and it works now !). So what I was missing since the beginning is that the way phpunit runs the tests and the way Apache is configured are two separate things with no interaction between them. I was wrong to try to force usage of my Apache alias.

Now I have something like that (and the simplicity talks for itself) :

$client = static::createClient() ;
$client->followRedirects ;
$crawler = $client->request(GET, '/myroute') ;

I guess phpunit uses the built-in server, but I have found no clue of that.

The only thing I can't do is to use $this->getUrl(), because I still have router.request_context.* parameters set with my Apache configuration (we need it for something else). But this is not an actual issue, because the cookbook recommends to have hardcoded URLs in tests (https://symfony.com/doc/2.8/best_practices/tests.html#hardcode-urls-in-a-functional-test).

Anyway, there is no bug here.

[jakzal]

I guess phpunit uses the built-in server, but I have found no clue of that

Phpunit does not use the built-in server. Web test cases are not run in a context of a web server at all. Instead, Symfony kernel is created and called directly (there's no http request).

[remipIGN]

Thank you for your reply.
Yes we figured that out aftewards (it seems so obvious today...), and it helped a lot to our understanding of phpunit. Now it's better and we caught up our late with unit testing.