search

imbo / behat-api-extension

API extension for Behat, used to ease testing of JSON-based APIs
MIT License
107 stars 42 forks source link

Base-uri check if behind proxy #98

Closed Taluu closed 3 years ago

Taluu commented 3 years ago

Hi,

I'm currently using Symfony-cli for my environment, and have the proxy started through it, using one of the attached domains I configured.

After setting it in my base_uri config, I always get can't connect to <....>, even when setting the HTTPS_PROXY env var : that is because this is not supported through the fsockopen call (guzzle supports this env var setting).

So I can't even start my behat start without commenting the check on the ApiClientAwareInitializer (around line 45). Once the exception throwing is commented, I can run just fine my requests.

TBH, I don't think it should be the responsability of the initializer to check if the base_uri is reachable or not...

christeredvartsen commented 3 years ago

I'm currently using Symfony-cli for my environment, and have the proxy started through it, using one of the attached domains I configured.

So basically you are using a combination of symfony server:start and symfony proxy:start? If you could provide some more info as to how to start up the project you want to test I would love to see if I can replicate it locally.

TBH, I don't think it should be the responsability of the initializer to check if the base_uri is reachable or not...

How about having a configuration option to disable this check?

Taluu commented 3 years ago

Yep, the proxy:start allows to start an automatic proxy that allows you to resolve your .wip domains (by default) to the local server (e.g 127.0.0.1:8000) on the port 80.

It's all in there : https://symfony.com/doc/current/setup/symfony_server.html#local-domain-names

And why not for the configuration, even if I'm pretty convinced it shouldn't be the responsability of the extension to make a check on the base_uri, and let it crash on the first error...

christeredvartsen commented 3 years ago

And why not for the configuration, even if I'm pretty convinced it shouldn't be the responsability of the extension to make a check on the base_uri, and let it crash on the first error...

I don't really have a strong opinion on this, and removal of code does make me happy, so why not. I'll push a pull request removing the check.

christeredvartsen commented 3 years ago

@Taluu Care to test the branch in the PR mentioned above and see if it works better?

Taluu commented 3 years ago

Well, I already did something similar (just commented out the throw) to be able to test the stuff I was working on, so it should be ok

christeredvartsen commented 3 years ago

PR merged. I will try to push a new release soon-ish. Feel free to use the dev-develop version until there exists a version with this fix.