-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exotic Proxy support #86
Comments
I will be implementing this change locally over the weekend, since I need it now, and will offer a pull request early next week. In the meantime, I'd love to hear any thoughts on this proposal. (Though I am camping through mid-sunday, so won't be replying asap) |
On closer examination, it just seems like changing the proxy server to always change origin might be enough, as url::parse handles pretty much everything else I'd considered in the original post. My original question of when |
Hey @DavidSouther, I'm not sure, what is the missing feature ? This should work just fine:
|
That does not work for http servers using name-based virtual hosts (which happen to be the only configuration I use :)) |
I just put
So I'm still confused, what am I missing ? Why specifying proxy with object (your proposal):
Would be better than current:
|
I believe I have muddled the issue. I no longer see any issues with the current syntax for defining proxies- that was a misunderstanding on my part of the proxy configuration method. My issue with proxies is that It if would help, I could close this issue and open a new ticket for changeOrigin specifically, but it still falls under more "exotic" proxy support (albeit without needing changes to the configuration). |
Slight edification: if there were additional configuration options that needed to be set on a per-proxy basis, an extended configuration block could be necessary. That would require reworking the proxy configuration to have one proxy per proxies entry. I don't think that is needed at this point. |
I am trying to do something like proxies = {
"/" : "https://local-domain/"
}; And I am getting an error something like
And the testacular browser console give something like
Is there any possibility of e2e testing on an https based website? |
At this point, testacular doesn't set up https proxies. You should serve
|
Ouch! That hurts. |
@rishabhmhjn Created issue/feature request for it https://github.com/vojtajina/testacular/issues/293 |
I guess the repository moved. Re-referencing - #293 |
I am having trouble using the proxy, my shared.conf.js has but when I run my scenario.js I get an error; Chrome 28.0 (Windows) E2E: Testing for Smoke should verify the test server is on FAILED I am running a application on mydomain:8088 Is this not a normal setup? What more must be done with the proxy, I am having trouble finding any examples of this. Thanks for the help. |
Proxy support currently only works for the most basic URL renaming situations. Anything more exotic, like
will generally fail, because the underlying HTTP Proxy isn't correctly configured to change origin, etc. I propose an extended syntax for proxies:
with path being the minimum required; with no other options,
'url'
and{path:'url'}
would be equivalent.The text was updated successfully, but these errors were encountered: